Article View: gnu.emacs.bug
Article #1703File locking on shared filesystems
From: cs126045
Date: Sun, 07 May 1989 20:54
Date: Sun, 07 May 1989 20:54
44 lines
2218 bytes
2218 bytes
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
Technical Details
Message-ID:
<8905072054.AA15176@transit.cs.brown.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!CS.BROWN.EDU!cs126045References:
<8905072040.AA04514@odin.think.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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