[8684] in Athena Bugs
vax 7.3P: afs and movemail
daemon@ATHENA.MIT.EDU (David Krikorian)
Wed Nov 27 22:57:30 1991
Date: Wed, 27 Nov 91 22:55:52 -0500
From: David Krikorian <dkk@Athena.MIT.EDU>
To: bugs@Athena.MIT.EDU
Reply-To: dkk@mit.edu
Since IS is apparently planning to migrate from NFS to AFS this
summer, the following bug report should be taken seriously. Loss of
mail can result (and almost did...) from the bug.
------------
System name: NW12-326-1
Type and version: CVAXSTAR 7.3P
Display type: SM
What were you trying to do?
I was trying to read my email.
More specifically, I indirectly (via rmail) invoked movemail
to bring my mail from my pobox to my homedir, so I could read
said mail. The problem was that my pobox was overflowing with
some bozo's sampled sound (1760 Kbytes worth).
What's wrong:
movemail got my mail from e40-po, wrote it to the afs cache,
told e40-po that the mail had arrived safely, and watched
blithely as afs threw it away... I was under quota before
movemail ran, far over quota afterwards. (afs homedir)
Excerpted from the console:
17:57 afs: failed to store file (over quota)
This happened as movemail was writing the file ~/Mail/po:dkk~,
which is where the incoming mail is copied to before rmail
gets it. I watched the file grow "in my homedir," then
suddenly vanish upon close(). A quick grep for "close" in
/usr/athena/lib/gnuemacs/etc/movemail.c indicates that
movemail doesn't always check the status of close(). This is
a lose.
I was able to recover my lost email by extraction from the
nicely-large afs cache on this machine, but I could easily
have been screwed since I usually read mail on a VS2...
What should have happened:
I should not have needed to rely on raw access to the afs
cache in order to read my mail.
Please describe any relevant documentation references:
None. I may have made some errors in my description of the
above incident, as I wrote from memory, not a reference.
