Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!jgd@csd4.milw.wisc.edu From: jgd@csd4.milw.wisc.edu (John G Dobnick,EMS E380,4142295727,) Newsgroups: comp.mail.elm Subject: Re: Problem With Network Disconnects And Locks Message-ID: <2222@csd4.milw.wisc.edu> Date: 24 Apr 89 21:26:39 GMT References: <5081@pbhyf.PacBell.COM> Sender: news@csd4.milw.wisc.edu Lines: 35 From article <5081@pbhyf.PacBell.COM>, by rob@PacBell.COM (Rob Bernardo): > In article <996@itivax.iti.org> scs@vax3.iti.org (Steve Simmons) writes: > [Rob answers Steve Simmon's question about .lock files in /usr/spool/mail] > > 1. If the system can do flock(), elm will use it just in case > it is the way mailboxes get locked on the system. > 2. All systems will lock with a lock file. > > This way Configure can't go wrong and the extraneous locks don't hurt. Well... almost. Unless the system crashes, or a network interface crashes, or the user gets disconnected, or... Then the .lock file stays around, causing no end of confusion. (Unless, of course, a reboot clears these files. But then who puts code into /etc/rc.local to do this? We don't. [Maybe we should?]) I would think the advantage of using flock() is that a reboot clears *all* them ugly locks, and resets the mail system to a "known state". (Yes, I got bitten by the "Your mailbox is busy, please wait" problem. Took a while to figure out what was happening.) I vote with the BSD-ites who claim flock() is sufficient, and that the lock files can be dispensed with. (Unless someone can convince me they really *are* required -- in addition to flock().) -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee INTERNET: jgd@csd4.milw.wisc.edu UUCP: !uwvax!uwmcsd1!jgd "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire