Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!CS.BROWN.EDU!cs126045
From: cs126045@CS.BROWN.EDU
Newsgroups: gnu.emacs.bug
Subject: File locking on shared filesystems
Message-ID: <8905072054.AA15176@transit.cs.brown.edu>
Date: 7 May 89 20:54:54 GMT
References: <8905072040.AA04514@odin.think.com>
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 44


   Date: Sun, 07 May 89 16:40:15 EDT
   From: taylor@Think.COM

   <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.

Well, we only have a few servers, and our lock directory is on the
same server as emacs itself, so we'd be hung in this case anyway.
Good point though.

   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.

Sounds good, but both would require hassling your sysadmins in order
to get things working, I think.  Right now you don't have to be root
to get emacs installed...

   <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)''.

Maybe allow the user to write a predicate which determines whether or
not to use locking at all.

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

Nick