Path: utzoo!attcan!uunet!lll-winken!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!wuarchive!rice!rice!sun-spots-request From: dhesi%cirrusl@oliveb.atc.olivetti.com (Rahul Dhesi) Newsgroups: comp.sys.sun Subject: Re: Problems gaining/releasing exclusive file locks in Sun NFS Keywords: Miscellaneous Message-ID: <1990Oct26.221540.18776@rice.edu> Date: 26 Oct 90 23:10:00 GMT Sender: sun-spots-request@rice.edu Organization: Sun-Spots Lines: 21 Approved: Sun-Spots@rice.edu Originator: spots@titan.rice.edu X-Sun-Spots-Digest: Volume 9, Issue 339, message 9 X-Original-Date: 8 Oct 90 02:43:09 GMT X-Refs: Original: v9n334 Re the report from angst@batserver.cs.uq.oz.au about problems with lockf and fcntl for locking: Many moons ago I experimented with locking mechanisms under SunOS 3.5. I found that network-wide locking did not appear to work correctly, even though the lock daemons were up and running. I fell back to the old standard technique of creating a lock file. Despite rumors that that file creation over NFS might not be truly exclusive and atomic, I have had no problems. Since then, I've often seen complaints posted to Usenet about lockf and fcntl not working correctly for locking over NFS, and have always been relieved that I decided not to use them. Of course, when you use file creation for network-wide locking, you must store both host name and process id in the lock file, and supersede an existing lock if the locking process was on the local host and has crashed. You must also use a secondary lock before manipulating the primary lock, so any race condition is minimized to infinitesimal probability. Rahul Dhesi UUCP: oliveb!cirrusl!dhesi