Path: utzoo!attcan!uunet!ginosko!husc6!ogccse!schaefer
From: schaefer@ogccse.ogc.edu (Barton E. Schaefer)
Newsgroups: comp.mail.mush
Subject: Re: truncated files?
Message-ID: <4434@ogccse.ogc.edu>
Date: 28 Aug 89 17:14:00 GMT
References: <6744@cs.utexas.edu> <4326@ogccse.ogc.edu>
Reply-To: argv@sun.UUCP (Dan Heller)
Organization: Oregon Graduate Center, Beaverton, OR
Lines: 31

[ The following was typed by Dan Heller and sent to me for posting because
  he's having some news problems.  -- Bart ]

In article <4326@ogccse.ogc.edu> schaefer@ogccse.UUCP (Barton E. Schaefer) writes:
> In article <6744@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes:
> } When mush incorporates newly arrived mail into the temporary
> } file, I've noticed that it occasionally truncates the new message.
> } The system mailbox is ok, but the file in $tmpdir is damaged.
> This is undoubtedly happening because your MTA is appending new mail onto
> the end of the mailbox at the same time that mush is reading the mailbox.
> If mush's read happens to go faster than the MTA's write, mush will see
> end-of-file before the message is complete.
> 
> The next version of mush will lock the file whenever possible during
> loading of new mail to avoid this problem.  Unfortunately, the SysV
> lockf() call only works on files opened for writing, so the precise
> implementation of this mechanism is still under discussion.

There is still the problem that not all MTAs lock the folder when appending
mail to it.  Granted, this is more applicatable to older MTAs, but I've
known some sun sendmail's that don't lock /usr/spool/mail/$USER folders
as recently as SunOS 3.2.  I can't make guarantees for sys-v's, xenix's
or other unix's MTAs, so let's hope people use "real" MTAs to avoid this
problem... :-)

					--dan
-- 
Bart Schaefer           "And if you believe that, you'll believe anything."
                                                            -- DangerMouse
CSNET / Internet                schaefer@cse.ogc.edu
UUCP                            ...{sequent,tektronix,verdix}!ogccse!schaefer