In article <1992Sep30.185131.5200@leland.Stanford.EDU>, mosedale@fafner.stanford.edu (Dan Mosedale) writes:
>
>1) Mail user agents (/usr/ucb/mail -- Ultrix & SunOS, elm, etc.)
>generally use a second file to lock the mailbox such as
>/usr/spool/mail/mosedale.lock. This seems to keep many problems at
>bay.
Doesn't ELM use /tmp/mbox.<username> though? I just ran a little
experiment where I sent myself mail and then started up ELM on both
`burn' and `phoenix'. I was able to bring ELM up on both machines
because they of course have different /tmp directories. I deleted the
mail and quit from ELM on phoenix, then went to the ELM on burn. I was
able to display the mail fine. Then when I hit `i' to return to the
index, it thinks new mail has arrived (I guess because quitting on
phoenix changed the date on the mail file?), checks things, and barfs
with:
Reading message: 0
newmbox - length of mbox. != spool mailbox length!!
Write to temp file failed, exiting leaving mailbox intact!
This is understandable behavior considering what's going on here, but
it's quite possible to forget that you left an ELM running somewhere and
try and start up another one... I guess the second program doesn't even
ELM...
Is there any particular reason the lock file was put in /tmp and not in
the mail spool directory?
Anyway I haven't really studied locking and NFS and such, so I'm not
pretending to propose any solutions or criticize the way things were
done... just reporting something that perhaps should be considered.
----------- The opinions expressed in this article are solely mine. -----------
<Insert lame attempt at disclaimer humor>
sss/PU'94 Dept of CS (spencer@phoenix.princeton.edu)/JvNCnet (spencer@jvnc.net)
"Horror? Steckle, it's ignorance we fear. Since when did truth and
knowledge become a horror?"
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:50 CDT