argv@turnpike.Eng.Sun.COM (Dan Heller) (02/12/91)
In article <1991Feb9.202900.20979@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: > As quoted from <LIBOVE.91Feb5102529@libove.det.dec.com> by libove@libove.det.dec.com (Jay Vassos-Libove): > +--------------- > | She ran mush to read her mail, read the first message, and when mush > | went to update the mailbox to report the arrival of new mail during > | her mail reading session, it complained about the mailbox being corrupted. > +--------------- > Two possibilities: > > (1) Does Mush know that SCO UNIX uses MMDF maildrops? Yes, Mush knows about MMDF. > Rather than depending > on a mail message starting with "From " at the beginning of a line, MMDF > delimits all messages with a line of four control-A (ASCII 1) characters. > A program expecting "From " could get confused by this. Mush knows this even tho this has nothing to do with the file-locking problem. Also note that the user was reading mail -- had Mush not known about the ^A's, the user would never have gotten that far. > +--------------- > | Is this a sign of very bad timing in a system that doesn't even try to > | use locking? Since I recall that mush uses some form of locking, is this > | a failure of locking due either to a bug in SCO Unix or in the way I > | configured mush? > +--------------- > MMDF does locking. It does *not* do the kind of locking standard /bin/mail > does (note that SCO's /bin/mail does MMDF locking now), so Mush is probably > using the wrong locking scheme. No, SCO UNIX is doing something wrong, but it's hard to tell exactly what it is. Mush uses the exact same locking that MMDF does, but SCO's MMDF is just a little tweaked in some areas so that it's not quite right. I run Mush (and zipmail) on my SCO box running MMDF (and ODT) and have tried to reproduce the problem. Altho I couldn't, I did notice that there is a small window of opportunity where MMDF should be locking a file, but waits a little bit (don't know why). If the system happens to be "loaded", I would imagine that this window of opportunity grows bigger and the chance of a lock failure is greater. It's possible that this is what happened in the case noted in the previous mail. I wouldn't bet that this is easily reproducible. -- Dan Heller ------------------------------------------------ O'Reilly && Associates Zyrcom Inc Senior Writer President argv@ora.com argv@zipcode.com