Path: utzoo!mnetor!uunet!husc6!mailrus!rutgers!iuvax!bsu-cs!cfchiesa
From: cfchiesa@bsu-cs.UUCP (Christopher Chiesa)
Newsgroups: comp.os.vms
Subject: Re: MAIL bug?
Message-ID: <2657@bsu-cs.UUCP>
Date: 20 Apr 88 17:38:34 GMT
References: <880415094610.000023950D2@naif.JPL.NASA.GOV>
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 73
Summary: Mail bug COMMON!

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