[nos-bbs] mailbox.usr and mailbox.inf file

Fri Oct 24 23:49:54 EDT 2014

Thanks Bob.  Some follow-up below.

If you delete a message you will see that its id remains in the area.usr
file.
If you check into a public area  "your_call  0" is written to area.usr if
you never logged into that area and
the "0" is overwritten with the id of the last message you have read at the
moment that you switch over to another area

and when you log out otherwise just the old id is overwritten for your call
if you are already in area.usr.

Got it.

You will also see calls appended with an underscore in area.usr and these
indicate errors mostly with a bbs,
a message is not forwarded because something goes wrong with a transmission,
etc.  The underscore just means
something like, forget what I have said.

Hmm.  Not following you there.   So if I see an entry in mailbox.usr like
"callsign_ 0", where "callsign" is a BBS but mailbox is not an area that I
forward to him, what does that mean?

Only the id of the last message is written, so it doesn't overwrite after
each message. Other stuff is kept somewhere else.

O.K.  But that still doesn't explain the (real) scenario I presented below.
Specifically:

The message numbers rollover at some point as shown below.  So when that
happens, it would seem that the entry in .usr needs some way to know that
smaller message numbers have actually not been read.  And that is the
problem.  The user is being told "0 new" when, in fact, he is sure that he
hasn't read at least the last one.

The function definitions who write to usr are in bmutil.c

That would be nice if I were a C programmer!  ;-)

Michael

73,

Bob VE3TOK

 On 14-10-24 02:27 PM, Michael E Fox - N6MEF wrote:

Thanks Bob.

I'm seeing something weird.

In mailbox.usr, an individual has a last read number of 29335.  But the
three messages in that mailbox.txt file are numbered 28560, 6039, and 14880,
respectively.  So apparently, the numbers used in .txt roll over at some
point but the last read number recorded in .usr doesn't.  So this user gets
"0 new" messages when he logs in, but, in fact, he is certain he hasn't read
at least the last one.  Unless the numbers in .usr are updated when the
message numbers roll over, it seems the algorithm is doomed to never work
correctly.

Very strange.  Does anyone know how this process is supposed to work?

Michael

From: nos-bbs-bounces at tapr.org <mailto:nos-bbs-bounces at tapr.org>
[mailto:nos-bbs-bounces at tapr.org] On Behalf Of Boudewijn (Bob) Tenty
Sent: Wednesday, October 22, 2014 10:12 AM
To: TAPR xNOS Mailing List
Subject: Re: [nos-bbs] mailbox.usr and mailbox.inf file

>1)  The mailbox.usr file holds a call sign and a number on each row.  What
does the number represent?

part of the message id of last message read

ve3tok 208448

Received: from port.ve3mch.ampr.org by port.ve3mch.ampr.org (JNOS2.0j.X)
with SMTP
    id AA208448 ; Wed, 22 Oct 2014 14:27:07 +0000

73,

Bob VE3TOK

On 14-10-22 10:30 AM, Michael E Fox - N6MEF wrote:

For a given JNOS mailbox, there are several files:

-- mailbox.txt holds the actual messages in mbox format

-- mailbox.ind holds the index

-- mailbox.inf - don't know

-- mailbox.usr holds which users have read up to which message

Two questions:

1)  The mailbox.usr file holds a call sign and a number on each row.  What
does the number represent?

For example, if the line contains "n6mef 0", what does that mean? And how is
that different from not listing the call sign at all?

As another example, if the line contains "n6mef 1000", what does that mean
and how does that relate to the Message-Id: header in the messages stored in
mailbox.txt?

2)  What is the purpose of the mailbox.inf file?

Thanks,

Michael

N6MEF

_______________________________________________
nos-bbs mailing list
nos-bbs at tapr.org <mailto:nos-bbs at tapr.org> 
http://www.tapr.org/mailman/listinfo/nos-bbs

_______________________________________________
nos-bbs mailing list
nos-bbs at tapr.org <mailto:nos-bbs at tapr.org> 
http://www.tapr.org/mailman/listinfo/nos-bbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20141024/15949095/attachment.html>