Xref: utzoo comp.mail.misc:5243 comp.protocols.nfs:2179 Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!mips!zaphod.mps.ohio-state.edu!wuarchive!rex!uflorida!screamer!tscs!tct!chip From: chip@tct.com (Chip Salzenberg) Newsgroups: comp.mail.misc,comp.protocols.nfs Subject: Re: Symlink locking considered useless over NFS Message-ID: <280EE8A1.30D@tct.com> Date: 19 Apr 91 12:54:56 GMT References: <2800BA22.1CAE@tct.com> <1991Apr09.160512.1300@chinet.chi.il.us> <3064@cirrusl.UUCP> Organization: Teltronics/TCT, Sarasota, FL Lines: 27 I sent Rahul mail on this subject some time ago, but he seems not to have received it; thus this article debunking his locking "solution". According to Rahul Dhesi : >The usual technique for locking with a lock file ... The ... problem >is that exclusive creates do not work over NFS. Solution follows. > >int get_a_lock() >{ > if (create(symlink called MUTEX that points anywhere) == failed) { > die("serious problem -- can't create MUTEX"); > } 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. 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. -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg ,