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