Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!olivea!oliveb!veritas!tron From: tron@Veritas.COM (Ronald S. Karr) Newsgroups: comp.mail.misc Subject: Re: Will ELM ever use lockf()? Message-ID: <1991Apr11.024849.29924@Veritas.COM> Date: 11 Apr 91 02:48:49 GMT References: <2800BA22.1CAE@tct.com> <1991Apr09.160512.1300@chinet.chi.il.us> Organization: VERITAS Software Lines: 41 In article <1991Apr09.160512.1300@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >You should be aware though that the smail3 mailbox locking code is >not particularly robust when using lockfiles. >... >Failure scenario: > Process A owns lockfile - Processes B & C are contending for one. > B reads A's PID from lockfile. > A finishes, removes lockfile and exits. > B sends signal 0 to A's PID, notes that process is gone. > C notes that no lockfile is present and creates one. > B removes lockfile (now belonging to C) and creates one. > At this point both B and C think they have exclusive access to > the mailbox. However, both smail3 and elm create the files using the O_EXCL flag, indicating that the OS should ensure that only one of the two creates should succeed. Thus, failure of the locking mechanism in the way that you describe requires that the underlying operating system fail to obey the O_EXCL semantics. An important case to point out is that NFS does not obey the O_EXCL semantics between two different client machines. As such, mailbox locking is broken on machines that do not use lockf(), which includes all sun machines as far as I know. The only solution is to either change smail and all of the mail readers to use lockf(), or to never send and receive mail from two clients sharing the same NFS /usr/mail directory. Landon Noll and I (the two smail3 authors) carefully considered this problem some years ago and determined that the only solution was for sun to admit that there was a problem and for them to start using lockf(), just like 4.3bsd does. However, the people that we talked to didn't believe us, always mounted their mailbox directory over NFS and had never seen the problem. Of course, the reason people almost never see the problem is that the window is extremely small given that an average mailbox receives only a few messages (up to 100) per day, and given that the window of vulnerability is typically sub-second. -- tron |-<=>-| ARPAnet: veritas!tron@apple.com tron@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron