lockf and the SVID, (Was "Re: Wanted: lockf system call source")

[Jim Hutchison]

Article <5413 at brl-smoke.ARPA> gwyn at 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 at sdcsvax.ucsd.edu
    "Yes, yes, ofcourse I disclaim everything.  No,no that is not my tape..."