fletcher@cs.utexas.edu (Fletcher Mattox) (08/23/89)
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. For example, the last message in /tmp/.mush.624588 currently looks like: From daemon Tue Aug 22 15:09:48 1989 Posted-Date: Tue, 22 Aug 89 15:09:37 CDT Received-Date: Tue, 22 Aug 89 15:09:38 CDT Message-Id: <8908222009.AA10202@cs.utexas.edu> Received: by cs.utexas.Received: by cs.utexas. There is no trailing newline on the obviously mangled last line of the file. For reference, my system folder, ~/mailbox has headers in tact: From daemon Tue Aug 22 15:09:48 1989 Posted-Date: Tue, 22 Aug 89 15:09:37 CDT Received-Date: Tue, 22 Aug 89 15:09:38 CDT Message-Id: <8908222009.AA10202@cs.utexas.edu> Received: by cs.utexas.edu (5.59/1.39) id AA10202; Tue, 22 Aug 89 15:09:38 CDT Date: Tue, 22 Aug 89 15:09:37 CDT X-Mailer: Mail User's Shell (6.5 4/17/89) From: daemon@cs.utexas.edu (The devil himself) To: daemon@cs.utexas.edu Subject: Error spooling ehandler.ps to -Plw1 <body of message deleted> I #define DOT_LOCK and HOMEMAIL. I "set tmpdir=/tmp". It happens with 6.5.6, though I've seen it as far back as 6.5.1. This seems to happen only when the system folder gets large, i.e. 300 messages with 500K data. It's not reproducible. Anybody else seen it? Fletcher
schaefer@ogccse.ogc.edu (Barton E. Schaefer) (08/23/89)
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. } } It happens with 6.5.6, though I've seen it as far back as 6.5.1. } This seems to happen only when the system folder gets large, } i.e. 300 messages with 500K data. It's not reproducible. } } Anybody else seen it? 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 a preliminary attempt at it in the 6.5.6.13 mushview beta version currently available for ftp from ucbvax. -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
schaefer@ogccse.ogc.edu (Barton E. Schaefer) (08/29/89)
[ 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
fletcher@cs.utexas.edu (Fletcher Mattox) (08/29/89)
In article <4434@ogccse.ogc.edu> argv@sun.UUCP (Dan Heller) writes: >[ The following was typed by Dan Heller and sent to me for posting because > he's having some news problems. -- Bart ] >There is still the problem that not all MTAs lock the folder when appending >mail to it. There's not much mush can do in that case. The MTA is busted. >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. Actually sendmail isn't involved. /bin/mail delivers to /usr/spool/mail/$USER and the SunOS 3.2 /bin/mail does attempt to flock(2) it. Fletcher