Digital Man wrote to Dumas Walker <=-
Synchronet BBS for Linux Version 3.20a
Revision a Apr 27 2024 09:49 SMBLIB 3.00 GCC 12.2.0
I'd upgrade to v3.20d or later.
Noted. I upgraded my test system to the latest yesterday to try it out.
For some reason your board loses me from time to time. It seems random.
User's message scan pointers are stored in data/user/<user-num>.subs,
if you want to monitor changes to the user's file, look for any corruption, etc.
Also noted.
Also, if the user is logging on to multiple nodes or services (e.g.
web, nntp, ftp, mail, and telnet, ssh, or rlogin) concurrently, that
can cause race-conditions and user-surprises with message scan
pointers. That'd be something to keep an eye on as well.
FYI a couple of things I have determined since:
(1) per the logs, both times the user logged on yesterday morning, when
they supposedly got the bad packet and when they got the second (*) one, Synchronet reports that it scanned 55 areas. Based on what it says when I download a packet, and when another user downloads one, I am pretty sure
that is the number of areas joined and it was consistent.
(2) I asked then to describe how they determined there was an issue.
Multimail has a feature where you can press "L" and rotate through a
listing of All Areas, Active Areas (the ones with messages), and Subscribed Areas. Not sure if this is a Multimail issue, or maybe just something with
the Synchronet packets, but he says the "Subscribed" list is where he sees
that there are message areas missing.
I told him I was not sure that the "Subscribed" feature of Multimail was accurate. On my packets, for example, that feature doesn't work at all. I trust the "55 areas" info that Synchronet is reporting in the logs over
what Multimail is reporting.
(*) in the second packet, they had managed to reset their msg pointers so
no comparison in packet size would be valid there.
... Spelling is a sober man's game
--- MultiMail/DOS v0.52
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP