Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucla-cs!twinsun!eggert
From: eggert@twinsun.com (Paul Eggert)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS and SCCS/RCS
Message-ID: <1991Jun12.012536.28728@twinsun.com>
Date: 12 Jun 91 01:25:36 GMT
References: <1991May30.004325.5078@hal.com>
Sender: usenet@twinsun.com
Organization: Twin Sun, Inc
Lines: 26
Nntp-Posting-Host: ata

woodstck@hal.com (Nathan Hess) writes:

>I'm interested in finding out whether the methods used by SCCS and RCS
>for file locking are safe over NFS.

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: e.g. suppose root is running RCS and you allow root access
over NFS, bypassing the S_IRUSR|S_IRGRP|S_IROTH permission?  However,
the bug has never been reported in practice, and I can't reproduce the
problem on my network of Suns here with either real RCS programs or
with small test programs.

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.