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 -------