Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!srcsip!pavo!alarson From: alarson@SRC.Honeywell.COM (Aaron Larson) Newsgroups: gnu.emacs.bug Subject: Re: Re^2: Lock files Message-ID: <31274@srcsip.UUCP> Date: 15 Sep 89 17:12:39 GMT References: <922@mipos3.intel.com> <45625@bbn.COM> Sender: news@src.honeywell.COM Lines: 62 In-reply-to: jr@bbn.com's message of 15 Sep 89 03:01:33 GMT In article <45625@bbn.COM> jr@bbn.com (John Robinson) writes: I have always believed the best solution is to write the lock file right into the directory of the file you are locking. I've actually done this, the following is the header from the new source, if there's interest, I'll post it. /* The following provides a file locking mechanism for GNU emacs in which lock files are created in the directory where the file being locked exists (see LOCKFILEPREFIX & SUPERLOCK_FILE_NAME in paths.h). The previous file locking mechanism was to create lock files in a single directory that everybody had write access to, where the lock file name was the name name of the file being locked with "/" replaced by "!". The file contained the pid of the locking process, so that broken locks could be identified. The old file locking scheme could lose several ways: 1. In a network environment, a single point of contact for lock files results in bottlenecks, and single point failures. 2. In a network environment, pid numbers are not adequate to identify processes; machine names must be taken into account, as well. In point of fact, adding just the machine name is not enough in subnetted networks, but the probability that machines with the same name, having the same pid running emacs, for the same user id, both trying to modify the same file, is fairly low. 3. If a file was accessible via different paths, (e.g., the path name contained symbolic links, or was accessible via a different mount point) the lock file name wouldn't be the same, and access violations would arise. 4. Hard links give files different names, so lock file names don't match. The scheme implemented by the following code is to write lock files in the same directory as the file being locked (we still use a superlock file, and it too is in the same directory as the file being locked). The lock file contains the user name, pid, the date the lock was acquired, and the machine name on which the locking process is executing. Because the lock files are in the same dir as the file being locked, it gets around problems 1 & 2 above, and minimizes the impact of 3. You can however loose in different ways: A. If the file visited is a symbolic link, you still loose. This is also a problem for backup files, so presumably users are somewhat aware of it. B. Still doesn't handle hard links. We considered using the inode of the file, but you can loose in a large number of ways, and it complicates the locking strategy considerably. C. If you don't have write access to the directory where the file you are writing will go, you will be unable to lock the file. Once again, autosaves and backup files already have this problem, so presumably users are aware of it. D. If the name of the lock file coincides with the name of an existing file, AND if ask-user-about-lock returns T even though the user name is NIL, AND the user has write access to the file, then it is possible that data could be overwritten. A judicious choice of LOCKFILEPREFIX should reduce this possiblity to near zero. The following code implements the same interface as the previous file, and does not do any more file I/O than the old method. */