A user has reported an issue with message pointers. They are downloading QWK packets. I also read most of my mail via QWK and have not noticed an issue.
My system info:

Synchronet BBS for Linux Version 3.20a
Revision a Apr 27 2024 09:49 SMBLIB 3.00 GCC 12.2.0
JavaScript-C 1.8.5 2011-03-31
GLIBC 2.36
Debian GNU/Linux 12 (bookworm)

I have not had any reason to restore from backups in a while (knock on wood).

Here is there message:

For some reason your board loses me from time to time. It seems random.
What happens is I'll log on, grab my packet and find nothing in it.
Mostly.

This morning I logged on, downloaded my packet and the only echo to
which I was subscribed was "F1" which is a fantasy league for Formula
One racing.

So I went thru the list and re-upped all of my usuals then logged back
in and uploaded those plus the prepared packet for Cooking that I had
ready. Then downloaded the result. Needless to say the last-read
pointers had all been reset to zero when they fell off the list - so it
was a mighty packet.

Today's episode is the fourth in the past few weeks and it's beginning
to get old. So, I thought I'd speak up in case it is fixable from your
end or points to a deeper problem in your software. Have a sterling
day.
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: Message Pointers
By: Dumas Walker to digital man on Sun Jul 13 2025 09:16 am

A user has reported an issue with message pointers. They are downloading QWK packets. I also read most of my mail via QWK and have not noticed an issue.
My system info:

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.

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, 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.
--
digital man (rob)

Sling Blade quote #17:
Charles Bushman: A shovel just makes too goddamned much racket.
Norco, CA WX: 84.8øF, 47.0% humidity, 5 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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