TZUTC: 1100   
   MSGID: 50462.dove-syncdisc@12:1/2 2bf2989b   
   REPLY: 53516.sync@1:103/705 2bf2663b   
   PID: Synchronet 3.20a-Linux master/4bb08eded Dec 23 2024 GCC 10.2.1   
   TID: SBBSecho 3.23-Linux master/0481ad294 Jan 18 2025 GCC 12.2.0   
   COLS: 80   
   BBSID: ALTERANT   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.105   
     Re: imsg on incoming echomail   
     By: Digital Man to deon on Sat Jan 18 2025 06:10 pm   
      
   Howdy,   
      
    >  > I'm going to monitor it more closely to see if I can find out why I'm not   
    >  > seeing the message as I expect...   
    >   
    > Okay, please let me know what you find.   
      
   OK, I think I've figured out the sequence. As background, I access SBBS via my   
   laptop (using Muffinterm - but that shouldnt matter), and often leave the   
   terminal open for hours at a time.   
      
   Over night, my laptop will go to sleep, so the connection to SBBS would   
   eventually be terminated.   
      
   So this afternoon I did this:   
      
   a) Sent a test message to clrghouz (which would generate a reply), and killed   
   my network connection (simulating my laptop going to sleep and not logging   
   off).   
   b) Sync exported the message   
   c) Sync imported the reply   
   d) No update to msgs/0001.msg (when there should have been).   
      
   Here is some logging:   
      
   1) I checked the status of the 0001*msgs before doing (a).   
      
   [deon@rl8-2-1 data]$ ls -al msgs/0001.*msg   
   -rw------- 1 root root 367 Jan 19 16:32 msgs/0001.last.0.msg   
   -rw------- 1 root root 285 Jan 12 16:25 msgs/0001.last.10.msg   
   -rw------- 1 root root  82 Jan  9 18:14 msgs/0001.last.11.msg   
   -rw------- 1 root root 207 Jan  9 13:03 msgs/0001.last.12.msg   
   -rw------- 1 root root  59 Jan  9 08:22 msgs/0001.last.13.msg   
   -rw------- 1 root root  64 Jan  8 13:11 msgs/0001.last.14.msg   
   -rw------- 1 root root 133 Jan  8 08:13 msgs/0001.last.15.msg   
   -rw------- 1 root root  58 Jan  7 22:23 msgs/0001.last.16.msg   
   -rw------- 1 root root 567 Jan  7 22:10 msgs/0001.last.17.msg   
   -rw------- 1 root root 567 Jan  7 22:07 msgs/0001.last.18.msg   
   -rw------- 1 root root 235 Jan 19 12:13 msgs/0001.last.1.msg   
   -rw------- 1 root root  71 Jan 19 11:02 msgs/0001.last.2.msg   
   -rw------- 1 root root 306 Jan 19 10:57 msgs/0001.last.3.msg   
   -rw------- 1 root root  71 Jan 18 20:24 msgs/0001.last.4.msg   
   -rw------- 1 root root 235 Jan 18 20:19 msgs/0001.last.5.msg   
   -rw------- 1 root root 142 Jan 18 15:36 msgs/0001.last.6.msg   
   -rw------- 1 root root  71 Jan 18 15:31 msgs/0001.last.7.msg   
   -rw------- 1 root root  64 Jan 16 17:00 msgs/0001.last.8.msg   
   -rw------- 1 root root  59 Jan 16 11:04 msgs/0001.last.9.msg   
   -rw------- 1 root root  71 Jan 19 16:37 msgs/0001.last.msg   
   -rw------- 1 root root   0 Jan 19 16:37 msgs/0001.msg   
      
   2) Output of sbbsecho when the test message was sent, and the reply received   
   (b) and (c)   
      
   2025-01-19 17:11:01 Exported:     1 msgs                         pvt_test ->   
   PVT_TEST   
   2025-01-19 17:11:01 Exported:     1 msgs total   
   2025-01-19 17:11:02 SBBSecho (PID 309988) exiting with error level 0,   
   Packets(0 imported, 2 sent), EchoMail(0 imported, 1 exported)   
   2025-01-19 17:11:30 Importing /opt/sbbs/fido/inbound/000a1ebe.pkt (type 2e,   
   1.8KB) from 10:1/1 to 10:1/4   
   2025-01-19 17:11:30 Imported:     1 msgs                         pvt_test <-   
   PVT_TEST   
   2025-01-19 17:11:30 Imported:     1 msgs total   
   2025-01-19 17:11:30 SBBSecho (PID 309999) exiting with error level 0,   
   Packets(1 imported, 1 sent), EchoMail(1 imported, 0 exported)   
      
   3) A list of the 0001*msg files after the import - notice that 0001.msg is   
   still 0 bytes in size (and no change in mtime), and no other *last.msg files   
   have been changed.   
      
   [deon@rl8-2-1 data]$ ls -al msgs/0001.*msg   
   -rw------- 1 root root 367 Jan 19 16:32 msgs/0001.last.0.msg   
   -rw------- 1 root root 285 Jan 12 16:25 msgs/0001.last.10.msg   
   -rw------- 1 root root  82 Jan  9 18:14 msgs/0001.last.11.msg   
   -rw------- 1 root root 207 Jan  9 13:03 msgs/0001.last.12.msg   
   -rw------- 1 root root  59 Jan  9 08:22 msgs/0001.last.13.msg   
   -rw------- 1 root root  64 Jan  8 13:11 msgs/0001.last.14.msg   
   -rw------- 1 root root 133 Jan  8 08:13 msgs/0001.last.15.msg   
   -rw------- 1 root root  58 Jan  7 22:23 msgs/0001.last.16.msg   
   -rw------- 1 root root 567 Jan  7 22:10 msgs/0001.last.17.msg   
   -rw------- 1 root root 567 Jan  7 22:07 msgs/0001.last.18.msg   
   -rw------- 1 root root 235 Jan 19 12:13 msgs/0001.last.1.msg   
   -rw------- 1 root root  71 Jan 19 11:02 msgs/0001.last.2.msg   
   -rw------- 1 root root 306 Jan 19 10:57 msgs/0001.last.3.msg   
   -rw------- 1 root root  71 Jan 18 20:24 msgs/0001.last.4.msg   
   -rw------- 1 root root 235 Jan 18 20:19 msgs/0001.last.5.msg   
   -rw------- 1 root root 142 Jan 18 15:36 msgs/0001.last.6.msg   
   -rw------- 1 root root  71 Jan 18 15:31 msgs/0001.last.7.msg   
   -rw------- 1 root root  64 Jan 16 17:00 msgs/0001.last.8.msg   
   -rw------- 1 root root  59 Jan 16 11:04 msgs/0001.last.9.msg   
   -rw------- 1 root root  71 Jan 19 16:37 msgs/0001.last.msg   
   -rw------- 1 root root   0 Jan 19 16:37 msgs/0001.msg   
      
   Interestingly, when I reconnected to the wifi (5 or so minutes later) and   
   logged another minute or so after that, Sync thought I was still connected to   
   Node 1 (obviously not long enough yet to kick me off, even though Muffinterm   
   had noticed (after rejoining the wifi) the TCP session was severed.   
      
   It also didnt show the message waiting status (M)?   
      
   Node Status   
   ÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ   
     1  deon posting message via telnet (P) [UQ]   
      
   Anyway, hopefully this is enough to see it in action. Its annoying, but I   
   guess I get why I dont see those messages alerts.   
      
   (And yes, I did a scan all new mail to me after I logged on, and saw the 1 new   
   message from PVT_TEST as expected).   
      
      
   ...ëîåï   
      
   ---   
    þ Synchronet þ AnsiTEX bringing back videotex but with ANSI   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 103/705 105/81 106/201 124/5016 128/187 153/757 7715 154/10   
   SEEN-BY: 154/30 110 203/0 218/700 221/0 226/30 227/114 229/110 114   
   SEEN-BY: 229/206 317 400 426 428 470 550 700 705 240/1120 5832 266/512   
   SEEN-BY: 280/464 5003 5006 291/111 292/8125 301/1 310/31 320/219 322/757   
   SEEN-BY: 341/66 234 342/200 396/45 423/120 460/58 256 1124 467/888   
   SEEN-BY: 633/280 712/848 770/1 902/26 5020/400 5054/30 5075/35   
   PATH: 103/705 280/464 460/58 229/426