Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!jade!ucbvax!utorphys.BITNET!SYSRUTH
From: SYSRUTH@utorphys.BITNET
Newsgroups: comp.os.vms
Subject: new mail during compress
Message-ID: <8712111649.AA12994@gpu.utcs.toronto.edu>
Date: 11 Dec 87 16:51:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 56


There are any number of ways in which your new mail counter can get out
of sync with the number of messages in your NEWMAIL folder. Greg Welych
is perfectly right, one of them occurs when you receive a new mail message
during a compress. If you watch the VMS messages during the compression,
you will see the following steps:
     
1. Temporary file mail_nnnn_compress.tmp is created (nnnn is probably
   taken from the time or something, to force a unique filename).
2. MAIL.MAI is copied, record by record, omitting those flagged as
   deleted, into the temporary file (thus the compression effect).
3. MAIL.MAI is renamed to MAIL.OLD.
4. mail_nnnn_compress.tmp is renamed to MAIL.MAI.
     
If you receive new mail during step 2, the new message will go into your
current MAIL.MAI file. Unfortunately, this is later renamed to MAIL.OLD,
and that is where you will find it (where you can still get at it, as
someone pointed out). If it arrives during step 1, it will get copied to
the new mail file along with everything else. But since step 2 is by far
the bulk of the time involved, it is the likeliest time.
     
It is interesting to note (although I haven't actually tested this) that
if mail were to arrive *between* steps 3 and 4, when you don't actually have
a MAIL.MAI file, VMS MAIL would probably create a new MAIL.MAI file with only
that message in it, and you would end up with two versions. Fortunately this
lasts only a tiny fraction of a second, so the chances are very small indeed;
small enough that the MAIL developers must have decided it wasn't worth
worrying about. There may be a mechanism for refusing MAIL at that time,
but since it doesn't refuse it during the rest of the operation, it seems
unlikely. Has anyone seen this happen?
     
I discovered a way of getting your counter out of sync the other direction,
which had more serious consequences. 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. Evidently being in NEWMAIL is not the only criterion for being considered
new MAIL. 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. 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
as the "bogus" one.
     
Curiouser and curiouser.
     
Ruth Milner
Systems Manager
University of Toronto Physics
SYSRUTH@UTORPHYS (BITNET)