Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!THINK.COM!taylor
From: taylor@THINK.COM
Newsgroups: gnu.emacs.bug
Subject: Re: File locking on shared filesystems
Message-ID: <8905072040.AA04514@odin.think.com>
Date: 7 May 89 20:40:15 GMT
References: <8905070035.AA13356@transit.cs.brown.edu>
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 38

<Date: Sat, 6 May 89 20:35:50 EDT
<From: cs126045@cs.brown.edu

<Problem: In the file locking code for GNU Emacs version 18.54, the
<current_lock_owner routine in filelock.c checks to see if a lock is
<obsolete by making a 'kill' system call with the process id found in
<the lock to see if the process which created the lock is still active.
<If the lock was put there by someone on another machine, the process
<which locked the file will not be found whether it is still around or
<not, and emacs will steal the lock without warning.

<Easy solution: unconditionally return(owner) in current_lock_owner
<before looking to see if the process is still around.  If the lock
<actually is obsolete the user always has the option of stealing it.

Unfortunately, it even worse.  Suppose the machine with the lock
directory crashes or is taken down and you try to lock a file from a
machine that's still up.  Your emacs ends up hanging.  Not good.

I feel that in an NFS environment, there should be a separate lock
directory for each diskfull machine -- and emacs should use the lock
directory that's on the machine that has the file being edited.  That
way, if the file is accessible, then so is the lock directory.

Alternatively, perhaps something based on or similar to the lock daemon.

<Better solution: allow users to set a lisp variable to select how
<cautious file locking should be.  If there's no risk of their files
<being edited by someone on another machine, the current code is fine.

I'd also like a way to say  ``don't lock files in this tree (say, home
directory on down), but do lock files in this other tree (source code
being edited by several people)''.

David
--
David Taylor
taylor@think.com, ...!think!taylor