Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!styx!ames!ucbcad!ucbvax!sdcsvax!hutch
From: hutch@sdcsvax.UCSD.EDU (Jim Hutchison)
Newsgroups: comp.unix.wizards
Subject: lockf and the SVID, (Was "Re: Wanted: lockf system call source")
Message-ID: <2264@sdcsvax.UCSD.EDU>
Date: Mon, 1-Dec-86 12:03:39 EST
Article-I.D.: sdcsvax.2264
Posted: Mon Dec  1 12:03:39 1986
Date-Received: Mon, 1-Dec-86 20:37:07 EST
References: <5413@brl-smoke.ARPA>
Reply-To: hutch@sdcsvax.UUCP (Jim Hutchison)
Organization: UCSD EMU Project (Educational Microcomputer Unix)
Lines: 27

Article <5413@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes:
>Dave, our Goulds have System V fcntl() record locking and they require
>(only) read permission to set a read lock, write permission to set a
>write lock.  I think it's pretty clear that requiring write permission
>for a read lock is poor design, whether intentional or not, and should
>be fixed in H-P's fcntl() implementation.  Note also that the SVID
>(Issue 2) states "The file-descriptor on which a read-lock is being
>placed must have been opened with read-access" and "The file-descriptor
>on which a write-lock is being placed must have been opened with write-
>access", the implication being that such access is also sufficient.

Not that H-P is at fault for following the mighty SVID, but why require
that the file-descriptor is open for write to do a write lock?  Wouldn't
any open file-descriptor do?  (note:  I do not have a copy of the SVID,
and am thus not fully informed of its content on this issue excepting
the referenced note)

I can see a reasonable scenario where a program reading a file might not
want the record it is looking at changed under it.  This would seem pretty
common when dealing with multiple processes accessing a database.  What
gives?

-- 
=
    Jim Hutchison   UUCP:	{dcdwest,ucbvax}!sdcsvax!hutch
		    ARPA:	Hutch@sdcsvax.ucsd.edu
    "Yes, yes, ofcourse I disclaim everything.  No,no that is not my tape..."