[comp.emacs] File-locking bug in NFS file-sharing environment

jr@bbn.com (John Robinson) (11/23/88)

In article <18209@shemp.CS.UCLA.EDU>, sdk@RA (Scott D Kalter) writes:
>We have discovered a bug in the file locking strategy for Emacs when
>being used in a multi-machine, shared file-system environment.  I
>would guess that we are not the first to discover it but I have not
>seen it discussed.

... and provides a detailed discussioin of his attempts to overcome the
problem.

This is a problem which emacs probably shouldn't attempt to solve.
The file system really ought to provide file locking, but
unfortunately Unix didn't come with it on day one.  Hence, lots of
user-level schemes, many like GNU emacs', have been invented to try to
cope.  If you accept that the emacs implementation was intended to be
portable, and came into being just as NFS was hitting the market, you
can probably accept that it doesn't attempt to solve the NFS locking
problem.

Sadly, even Sun hasn't really solved it right yet (at least in OS
3.4).  You have a choice of two systems calls.  flock(2), the original
from Berkeley, also predates NFS and only works across a single CPU.
It uses locks in the in-core inode table (I think).  Also, flock locks
only at the file (not record or character) level, which is not up to
modern file-management standards as used in, say, DBMS's.

lockf(2) and fcntl(2) allow locking stretches of the file, but are
completely separate from the flock mechanism.  They work on NFS files,
provided the file server is running a lockd and statd daemon.  In
other words, they work outside of NFS somewhat.  I don't know if other
NFS implementations interwork with these daemons properly, or if they
are required to.

Once you have found out that someone else owns the lockf/fcntl lock,
you get no useful information on who that might be (the calls return a
pid).  The daemons do, however, recover following a server or client
crash or network outage.

I believe that one of the goals of the GNU operating system design is
to improve on the file system in this area.  I don't know what POSIX
has propsed in this regard.

So, in summary.  The problem is not really emacs's to solve.
Unfortunately, the existing facilities provided may not be entirely
adequate or portable or standard.

If I am too pessimistic here, someone please corect me!
--
/jr
jr@bbn.com or bbn!jr