[comp.os.vms] MAIL bug?

PJS@NAIF.JPL.NASA.GOV (Peter Scott) (04/16/88)

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?

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

cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (04/21/88)

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?

Yes!  In my position as an all-purpose VaxCluster-user assistant and problem-
solver, this particular question arises REPEATEDLY.  You're not alone.

The problem is one of timing: new messages are placed in the file MAIL.MAI,
but the COMPRESS operation causes a RENAMING of the MAIL.MAI file.  So the
ultimate destination of the message depends on WHICH file is named MAIL.MAI
*AT THE TIME THE MESSAGE ARRIVES!*  Because file-renaming is the LAST part of
the COMPRESS process, the name MAIL.MAI points to the ORIGINAL or OLD mail
file, right up til the very last moment, when it is renamed as MAIL.OLD.  As
a result, messages arriving during a COMPRESS are about 99% likely to wind up
in the file that has the name MAIL.OLD after the COMPRESS.  I always advise
my "clients" to do the following, if a mail message arrives during COMPRESS:

1) DON'T immediately delete the MAIL.OLD file!  If you're running COMPRESS and
   a DELETE MAIL.OLD together in a command procedure, make the DELETE condi-
   tional on YOUR response to an INQUIRE, so that if you noticed mail arriving
   during the COMPRESS you can bypass the DELETE til you recover the new
   message.

2) Go into MAIL and use the command

      SET FILE MAIL.OLD

3) Use the SELECT, DIRECTORY, and READ commands to read any new messages you 
   received during COMPRESS.  DO NOT use DIR/NEW or READ/NEW, as these com-
   mands perform an implicit SET FILE MAIL.MAI which defeats step (2), above.

4) Use the MOVE or FILE command to transfer any messages you wish to keep, 
   over to the new MAIL.MAI file.  The command would look like this:

       MOVE foldername MAIL.MAI

5) When you've "saved" all messages you wish to, you may exit Mail and delete
   the file MAIL.OLD . 

This is a CURE for the problem AFTER it's occurred.  By and large, you can 
PREVENT the problem by setting mail FORWARDing before you do the COMPRESS, 
so that no mail even TRIES to get into your MAIL.MAI.   If you set the FORWARD-
ing to a non-existent username like "COMPRESSING_MY_MAIL__TRY_AGAIN_IN_2_MIN",
the sender will see a message of the form

     No such user "COMPRESSING_MY_MAIL__TRY_AGAIN_IN_2_MIN"

when he first enters your username at the TO: prompt on his end.

It's possible for the sender to bypass a SET FORWARD of this type, though, so
you still need to be alert for mail arriving during COMPRESS, but this will
at least make them think twice before going to the trouble.  

If you do the SET FORWARD trick, don't forget to SET NOFORWARD after you're
done COMPRESSing!  Oops!

This should take care of your Mail problems; hope it helps!

Chris Chiesa
"Helpdesk" Intern
University Computing Services
Ball State University
Muncie, IN                          (how much of this info is really necessary?)

:-)

-- 
UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa 
cfchiesa@bsu-cs.UUCP                                           

IVANOVIC%VAXR@CIRCUS.LLNL.GOV ("Vladimir Ivanovic, x3-7786") (04/21/88)

I seem to remember that it's a feature.  If you're compressing, then you
can't receive MAIL.  So I compress at 2 AM when everyone is asleep...hopefully.

-- Vladimir

root@helios.toronto.edu (Operator) (04/22/88)

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

WEBB%CPWSCA@VB.CC.CMU.EDU ("Bryan R. Webb") (04/24/88)

> Date: Fri, 15 Apr 88 09:46:10 PST
> From: Peter Scott <PJS@naif.jpl.NASA.GOV>
> Subject: MAIL bug?
> To: info-vax@kl.sri.com
> X-Vms-Mail-To: EXOS%"info-vax@kl.sri.com"
> Message-Id: <880415094610.000023950D2@naif.JPL.NASA.GOV>
>      
> 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?
>      
> Peter Scott (pjs%grouch@jpl-mil.jpl.nasa.gov)
 

I've also been the situation before where I was compressing my MAIL.MAI
file at the very moment mail arrived, but my mail was not lost because I
was not so hast to delete my MAIL.OLD file. 

The session went something as follows:

   MAIL> COMPRESS
   
   %MAIL-S-CREATED, USR$ROOT:[WEBB.MAIL]MAIL_004A_COMPRESS.TMP;1 created
   New mail on node COBRA from STREIX::STUBBORN
   %MAIL-S-COPIED, USR$ROOT:[WEBB.MAIL]MAIL.MAI;1 copied to 
      	        USR$ROOT:[WEBB.MAIL]MAIL_004A_COMPRESS.TMP;1 (327 records)
   %MAIL-S-RENAMED, USR$ROOT:[WEBB.MAIL]MAIL.MAI;1 renamed to 
      		USR$ROOT:[WEBB.MAIL]MAIL.OLD;1
   %MAIL-S-RENAMED, USR$ROOT:[WEBB.MAIL]MAIL_004A_COMPRESS.TMP;1 renamed to 
      		USR$ROOT:[WEBB.MAIL]MAIL.MAI;1
   
   MAIL> 

You see, the system delivered the mail while the original MAIL.MAI file
was still in place, but apparently put it in a place the compression had
already passed or just couldn't find.  Then, as the compression continued,
the MAIL.MAI file that my new message went to was now MAIL.OLD (and the
MAIL_aaaa_COMPRESS.TMP file without the new message became my MAIL.MAI).
All I had to do was to SET FILE MAIL.OLD in MAIL and read the new message
there. 

I don't think that this is a bug, and that it was handled pretty well.
About the only other way it could have been handled would have been to
make the system wait until the MAIL.MAI file was no longer locked by the
compression to deliver the message, but that would that would probably be
unreasonable to the sender (and people hate to wait). 

--Bryan Webb
User Consultant
Pittsburgh Supercomputing Center

-------