Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!hal.com!shap
From: shap@hal.com (Jonathan Shapiro)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS and SCCS/RCS
Message-ID: <1991Jun13.222234.8749@hal.com>
Date: 13 Jun 91 22:22:34 GMT
References: <1991May30.004325.5078@hal.com> <1991Jun12.012536.28728@twinsun.com>
Sender: news@hal.com
Organization: HaL Computer Systems
Lines: 51

In article <1991Jun12.012536.28728@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>
>This question pops up every so often.  I don't know about SCCS, but RCS
>5.5 locks a file foo,v by creating a lock file ,foo, with the system call
>
>	open(",foo,", O_CREAT|O_EXCL|O_WRONLY, S_IRUSR|S_IRGRP|S_IROTH)
>
>on the theory that if two processes attempt this call simultaneously,
>Posix says O_CREAT|O_EXCL prevents simultaneous access, and the
>S_IRUSR|S_IRGRP|S_IROTH should make the file readonly, preventing
>simultaneous O_CREATs even if the underlying system (e.g. NFS) botches
>O_EXCL.  I've heard rumors that in theory even this doesn't work all
>the time...
>
>Does anyone have some hard information about this problem?  The rumored
>workaround, which is to create a temporary file named T and then use
>link(T,L) to link it to the lock filename L, doesn't work under MS-DOS
>because MS-DOS lacks link().  Surely RCS is not alone in wanting to
>lock files over NFS.

Yes, I have some hard information.  Suspecting that this was the case,
I went in and looked at the implementation of the NFS code for the
client side on SVR4.  I suspect that the code is the same as taht used
in BSD and SunOS itself.

The bad news is that the NFS protocol which underlies all this crud
doesn't allow for the O_EXCL|O_CREAT state to be transmitted and
implemented by the server.  The O_EXCL to mean "only if it doesn't
exist" notion is not built in to the protocol.

To emulate the behavior as closely as possible, the client code for
SVR4 does a directory search with the directory inode unlocked
followed by a creat.

This leaves an open window of vulnerability, as follows:

	client 1 does dir search, finds file is not there
	client 2 does dir search, finds file is not there
	client 1 does creat, thinks it wins.
	client 2 does creat, which truncates client 1's file as a side
		effect.

The link(2) system call is implemented atomically, so the workaround
you described works.

Here at HaL our version of RCS uses the link trick - we rewrote the
locking code.  If link(2) isn't available on PC's I'm not sure how to
help.

Jonathan Shapiro
HaL Computer Systems, Inc.