🚀 go-pugleaf

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