Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!mipos3!pinkas From: pinkas@cadev5.intel.com (Israel Pinkas ~) Newsgroups: gnu.emacs.bug Subject: Re: Re^2: Lock files Message-ID: Date: 18 Sep 89 21:41:54 GMT References: <922@mipos3.intel.com> <45625@bbn.COM> <31274@srcsip.UUCP> Sender: news@mipos3.intel.com Distribution: usa Organization: Corporate CAD, INTeL Corporation, Santa Clara, CA Lines: 42 In-reply-to: alarson@SRC.Honeywell.COM's message of 15 Sep 89 17:12:39 GMT In article <31274@srcsip.UUCP> alarson@SRC.Honeywell.COM (Aaron Larson) writes: > 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. Your patch still does not address the problem introduced by the statelessness of NFS. In particular, NFS introduced a nasty problem of a race condition. If machines client-a and client-b mount a directory from server-1, a file created by a user on client-a might not be visible on client-b for up to a minute. You can get around the machine name problem on subnets by using the TCP address instead of the machine name. The harder problem is figuring out whether the lock is still valid. (i.e., did the other machine crash and leave a bogus lock.) You can't exactly use kill() or look at the process table to determine if the other process is running. You can almost eliminate the problem by using lockf() if you run the lock daemon. If both clients use this, you have network-transparent locking. You do not need a lock directory or file. You also don't have to worry about multiple hard links or soft links. (I say 'almost eliminate' because I am not 100% sure that you won't run into the race conditions.) I looked into it at one point, but since we still have Ultrix 2.2 file servers (that don't have the lock daemon), I haven't been able to really test it out. -Israel Pinkas -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas ARPA: pinkas%cadev4.intel.com@relay.cs.net CSNET: pinkas@cadev4.intel.com