Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Wanted: lockf system call source
Message-ID: <5413@brl-smoke.ARPA>
Date: Fri, 28-Nov-86 11:35:10 EST
Article-I.D.: brl-smok.5413
Posted: Fri Nov 28 11:35:10 1986
Date-Received: Mon, 1-Dec-86 06:37:27 EST
References: <110@dvm.UUCP> <2200003@hpisoa1.HP.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <2200003@hpisoa1.HP.COM> davel@hpisoa1.HP.COM (Dave Lennert) writes:
>One interesting thing I noticed about implementing lockf() on top of SysV
>fcntl() file locking is that (it appears) fcntl() requires that the file
>be opened with write permission even for read locking.  Lockf() does not
>require this.
>I'm I correctly stating the situation?  If so, is this regarded as a 
>deficiency in SysV's lockf()?

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.