Xref: utzoo comp.mail.misc:5250 comp.protocols.nfs:2184 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!kyle From: kyle@uunet.UU.NET (Kyle Jones) Newsgroups: comp.mail.misc,comp.protocols.nfs Subject: Re: Symlink locking considered useless over NFS Message-ID: <129674@uunet.UU.NET> Date: 20 Apr 91 19:31:35 GMT References: <1991Apr09.160512.1300@chinet.chi.il.us> <3064@cirrusl.UUCP> <280EE8A1.30D@tct.com> Followup-To: comp.mail.misc Organization: UUNET Communications Services, Falls Church, VA Lines: 29 chip@tct.com (Chip Salzenberg) writes about Rahul Dhesi's code: > This "solution" is nothing of the kind. > > NFS can report failure on a symlink creation (or on directory > creation) even if the operation succeeds. Any locking protocol that > depends on the return code of symlink or directory creation is not > robust over NFS. True, but using symlinks could be a start toward a solution. Instead of creating symlink pointing to a random place, why not put your hostname and process ID into the symlink? Then you could use readlink() to read the information back from the symlink and verify that it is your lock. This beats link() because you get a file creation _and_ one atomic write which you can use for identification purposes. > NFS's statelessness is supposed to be a feature. Well, as far as I'm > concerned, the designers of NFS can go take a flying leap, and they > can take their stateless protocol with them. No argument here. kyle jones ...!uunet!kyle Oh, yeah, that was that package that I was having so much trouble installing. There was a combination of things going wrong, and to make the story short, someone should go back in time and shoot the person who invented NFS. And then bugger the corpse. - one very unhappy system administrator