Orphaned Response

[nrh at faust.UUCP]

>/**** faust:net.bugs.4bsd / ki4pv!tanner / 10:09 am  Dec 18, 1985 ****/
>] utzoo!henry points out problem of fool opening/locking /etc/passwd
>] and claims that adding open("arg", O_READ|EXCL) re-invents flock()
>
>Doesn't re-invent flock() -- open()/flock() is not an atomic action.
>
>Security is easily solved by refusing to allow locking a file unless
>the file has been successfully opened for WRITE -- there's no real
>excuse for a read-only prog to need to lock a file if the write-file
>prog successfully locks the damned thing anyway.
>-- 
><std dsclm, copies upon request>	   Tanner Andrews, KI4PV
>uucp:					...!decvax!ucf-cs!ki4pv!tanner
>/* ---------- */

Not to carry this on too long, but I believe Tanner Andrews is
incorrect.  Very often one wishes to "share-lock" a file, so as to
ensure that it doesn't change while you read it.  The idea here is
that the file may be periodically updated by a master process and read
by processes which should not be able to write the file, but which 
which must read it only when the file is in a "consistent" state.

An example is a list of budget items, where the total cost is included
in the master file.  Change an item, and then read the file, and then
change the total, and you'll find the total read by the reading process
doesn't match the total of the items read by the reading process.

Standard practice is for the reading processses to  "share-lock" the 
file, read the items, read the total, and unlock the file.  Standard
practice for the writing process is to "exclusive-lock" the file, 
do the updates, and unlock.  The reading process doesn't need exclusive
locks (there might be many) but the writing process does.  The reading
process DOES need to guarantee that no updates happen among the reads.

Hope this is clear (and correct!)

						- Nat Howard