Path: utzoo!utgpu!jarvis.csri.toronto.edu!me!radio!helios!root
From: root@helios.toronto.edu (Operator)
Newsgroups: comp.os.vms
Subject: Re: MAIL bug?
Message-ID: <550@helios.toronto.edu>
Date: 21 Apr 88 18:31:29 GMT
References: <880415094610.000023950D2@naif.JPL.NASA.GOV>
Reply-To: sysruth@helios.physics.toronto.edu (Ruth Milner)
Organization: University of Toronto Physics/Astronomy Computing Consortium
Lines: 39

In article <880415094610.000023950D2@naif.JPL.NASA.GOV> PJS@NAIF.JPL.NASA.GOV (Peter Scott) writes:
>I was just executing a COMPRESS inside MAIL (after having read my INFO-VAX
>messages, needed to clean out the disk), and got an incoming mail message
>notification; I exited from MAIL and deleted my MAIL.OLD file (this was
>all still happening from typed-ahead commands), did a few other things,
>then went back into MAIL, and - surprise - no NEWMAIL folder.  No new
>messages in the MAIL folder.  Message vanished.  Anyone experienced this?
>
It was in your MAIL.OLD file. I posted an article about this a while back,
when there was a rash of questions about phantom mail messages. When you
do a COMPRESS, MAIL creates a temporary file which it then copies all the
active messages into (i.e., it isn't really a true compression in the
purest sense of the term - it is achieved by simply not copying anything
marked as deleted). When this has completed, it renames MAIL.MAI, the original
file, to MAIL.OLD, and renames the temporary file MAIL.MAI. However, if
a message arrives during the copy, it is naturally "delivered" to the file
called MAIL.MAI - which is the one that gets renamed to MAIL.OLD after
the whole process is finished. So that's where it is.

It's my opinion that this method leaves too many gaps when things could go
wrong. This is one of them. Another would be if a message arrived after
MAIL.MAI was renamed to MAIL.OLD, but before the temporary file was renamed
to MAIL.MAI. I assume that MAIL would try to create its own MAIL.MAI file,
and you would then have two MAIL.MAI's, one of which would have the original
messages, and the other with the new message. I think DEC should devise
some kind of "lock" on MAIL.MAI during a compress, but one which would merely
cause an incoming message to wait until the lock was removed, rather than
bouncing completely (which would be rude). I haven't noticed anything like
this on the DECUS SIR ballots, but perhaps DEC has noticed this internally
and will fix it in some future unmentionable release of VMS.

>Peter Scott (pjs%grouch@jpl-mil.jpl.nasa.gov)


-- 
 Ruth Milner          UUCP - {uunet,pyramid}!utai!helios.physics!sysruth
 Systems Manager      BITNET - sysruth@utorphys
 U. of Toronto        INTERNET - sysruth@helios.physics.toronto.edu
  Physics/Astronomy/CITA Computing Consortium