[nos-bbs] DUPES and staggered forwarding

[Michael Fox (N6MEF)]

OK.  But, when I mentioned this problem a month or so ago, the conversation turned to the bid number.  So, I figured the two numbers may be related.  Anyway, I guess we will still have a problem.

I sent test data a while back that shows the message numbers in .usr role over much lower, not 999,999,999.  More like 5 digits.  When they do, the number assigned to the next message is lower than the number assigned to the previous message read by the user.  In determining whether a message is new, JNOS only seems to care if the message number is greater than the number stored in .usr for that call sign.  So, after the number rolls over, JNOS thinks that all new messages have already been read.  So, the user may log in and see “0 new messages”, even when there are many new messages.  The worst case is when the user reads a message with a high number, just before it rolls over.  In that case, JNOS might forever more tell them there are no new messages in that mailbox.

It’s easy to replicate at will.  If needed, I can go back and find my original report and the details of how to reproduce.  Let me know.

Michael, N6MEF


Sent from my iPhone

> On Oct 23, 2020, at 15:59, M Langelaar <maiko at pcsinternet.ca> wrote:
> 
> Michael,
> 
> The number in mailbox.usr is actually taken from the numerical msgid
> which is taken from the mqueue/sequence.seq file, and that number is
> rolled over after 999999999, it's been that way since the linux version.
> 
> Dont' confuse BID rollover with the number's rolling over in usr file.
> 
> The BID sent out in bulletins is simply a modulus of that huge number,
> so when the range of the BID hits 99999, the modulus simply resets the
> BID to start over again, the sequence number itself keeps going. You can
> see that in the headers of any messages (message-id) after the BID rolls
> over, and if you search the code the %100000 is only used twice, fbbfwd.c
> and forward.c, has no effect on that msgid (sequence number) at all.
> 
> The BASE36 just gives us more 'numbers' for BIDs, nothing else.
> 
> Does that make sense ?
> 
> > Changing BID generation from base 10 to Base 36
> 
> >> Does this also apply to the number stored along with the callsign in
> >> <mailbox>.usr? If it does, then I think that will solve (or delay until I'm
> >> dead) one of the biggest problems we've had for >1 year (those numbers
> >> rolling over, causing JNOS to think we've already read older messages).
> 
> Maiko
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/nos-bbs_lists.tapr.org