Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.arch
Subject: Re: Locking, again
Message-ID: <582@rlgvax.UUCP>
Date: Sat, 16-Mar-85 14:44:52 EST
Article-I.D.: rlgvax.582
Posted: Sat Mar 16 14:44:52 1985
Date-Received: Sun, 17-Mar-85 23:12:21 EST
References: <1685@seismo.UUCP> <882@utcsri.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 49

> The reason I disagree, is that I see no reason why any operating system would
> allow someone to lock a file that they cannot write to.

What if program A wants to read, say, "/etc/passwd", and wants to make sure
nobody's writing on top of it while it reads?

Of course, another solution to this is to provide transaction atomicity
on the operation "replace contents of file".  In effect, you can create
a "replacement" for the file which isn't visible until you've written the
last block of the new copy and declared the transaction closed.

One way of doing this is to create a temporary file and rename it; this
technique is used in some UNIX software, including the S3/S5 "ed".  However,
it won't preserve links, doesn't work if you don't have write permission
in the containing directory (these two problems are handled by "ed" not
using this technique if the file has links or is in an unwritable directory),
and doesn't work if you can't give files away.  Furthermore, if the system
crashes before the rename, the temporary file is not cleaned up.

Another way is to support file "version numbers", Tenex/RSX/VMS style.
In this case, you don't do a rename which deletes the old version; you
just create a version with a higher version number.  When the new version
is being written out, it exists as the highest numbered version.  You
probably want to have this file specially flagged or locked, so that
nobody can open it until you're done.  You may want to return an error
on attempts to read it, or may want to block the process until the new
version is ready (which means you have locked the file), or you may want
to have the previous version opened.

A third way is to have the new file not have any directory entry pointing
to it until it's fully written out and you declare it "ready", at which
point its inode/file header/whatever replaces the previous version's, and
the previous version's blocks get returned to the free pool (unless somebody
has that file open, in which case you wait until they're done).  (Thanks
to Rick McShane for this idea.)

This does raise the question of what to do if process A has the file open
and process B starts updating it.  Should process A just keep a handle
to the old file with the now-stale data (which is probably acceptable in
a lot of instances), or should it somehow be notified that the data has
changed out from under it?  (It is assumed that process B can do this kind
of update; if you don't want it to, you have to do the sort of locking
mentioned above.)

All these arguments also apply to record locking and transaction
atomicity for record updates.
-- 
	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy