Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!CitHex.Caltech.EDU!carl
From: carl@CitHex.Caltech.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: new mail during compress
Message-ID: <871213091343.001@CitHex.Caltech.Edu>
Date: 13 Dec 87 17:14:16 GMT
References: <8712111649.AA12994@gpu.utcs.toronto.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 57


 > I discovered a way of getting your counter out of sync the other direction,
 > which had more serious consequences.

Actually, what you describe below doesn't get your NEWMAILCOUNT out  of  sync.
The  counter  is there (in SYS$SYSTEM:VMSMAIL.DAT) to keep track of the number
of messages you've received but not read.  Since you admit to having read  the
message,  the  fact  that  the counter has been decremented means it's working
properly.  Actually, you need not READ the message to have it  counted  as  no
longer  new;  FILEing  it  also  makes  it  an  old message and decrements the
counter.

 > If you read a new message, decide you want it back in your  new  mail,  but
 > instead  of  forwarding  it to yourself you just MOVE it to NEWMAIL, things
 > really get screwed up.  It isn't counted as a new message  (not  surprising
 > since  you have bypassed the normal delivery process), and it won't show up
 > in a normal read of new mail, either when you first go into MAIL or if  you
 > type  READ/NEW.   To get at it you have to SELECT NEWMAIL directly.  I find
 > this strange since I wouldn't have thought the number of new messages would
 > have  any  idea  *which*  messages  were  actually new.

You're right; the counter DOESN'T know which messages  are  or  are  not  new.
That's why it can get out of sync.

 > Evidently being in NEWMAIL is not the only criterion for  being  considered
 > new MAIL.

In order for a message to qualify as new, it must satisfy two criteria:
    1)  It must be in the NEWMAIL folder in the file  MAIL.MAI  in  your  mail
        directory (this is the condition you knew about); and
    2)  The low-order bit of the 49th byte  in  the  header  record  for  that
        message must be set.
If it weren't for the extra condition imposed on new messages, there  wouldn't
be  much  point  in the SELECT/NEW and READ/NEW, since the "SELECT NEWMAIL" or
"READ NEWMAIL" would provide the same functionality,  except  for  their  side
effect of reconciling the NEWMAILCOUNT with the actual number of new messages.

 > It doesn't matter what the date on the message is; you can have both  older
 > and  newer  ones  in  the folder, and the one that was MOVEd there will not
 > show up.  So it isn't simply a  case  of  only  displaying  the  number  of
 > messages the counter knows about.

Here again, the second criterion comes into play.  Since the message you MOVEd
has the `new' bit cleared, the /NEW commands ignore it.

 > Does anyone have an explanation for this  behaviour?   Are  there  actually
 > *two* NEWMAIL folders, the one you put the message in and the one with real
 > new MAIL in it?  I seem to  recall,  though,  that  after  doing  a  SELECT
 > NEWMAIL the real new messages showed up as well

No, there can only be one folder with a given name  in  any  mail  file.   The
folders  are  implemented  by  reserving  a  field in the header record of the
message in which the name of the  folder  to  which  the  message  belongs  is
stored.   This  field is associated with key  1 in the indexed file (key  0 is
the date and time the message arrived).  Given  this  implementation,  if  two
folders  in  the same file have the same name, they are by definition the same
folder.