Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: $Revision: 1.6.2.16 $; site faust.UUCP Path: utzoo!linus!decvax!cca!faust!nrh From: nrh@faust.UUCP Newsgroups: net.bugs.4bsd Subject: Re: Orphaned Response Message-ID: <3400002@faust.UUCP> Date: Tue, 7-Jan-86 18:12:00 EST Article-I.D.: faust.3400002 Posted: Tue Jan 7 18:12:00 1986 Date-Received: Fri, 10-Jan-86 06:12:14 EST References: <5517@allegra.UUCP> Lines: 38 Nf-ID: #R:allegra:-551700:faust:3400002:177600:1829 Nf-From: faust!nrh Jan 7 18:12:00 1986 >/**** 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. >-- > 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