Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!rutgers!husc6!necntc!frog!john
From: john@frog.UUCP (John Woods, Software)
Newsgroups: comp.unix.wizards
Subject: Re: lockf and the SVID, (Was "Re: Wanted: lockf system call source")
Message-ID: <1169@frog.UUCP>
Date: Tue, 2-Dec-86 14:51:19 EST
Article-I.D.: frog.1169
Posted: Tue Dec  2 14:51:19 1986
Date-Received: Wed, 3-Dec-86 22:09:01 EST
References: <5413@brl-smoke.ARPA> <2264@sdcsvax.UCSD.EDU>
Organization: Superfrog Heaven [ CRDS, Framingham MA ]
Lines: 24

> 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....
> 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?

I believe that the original message was about the routine named "lockf()",
which in SVID requires O_WRONLY or O_RDWR permission.  fcntl() read-only
locks require O_RDONLY or O_RDWR, and write locks require O_WRONLY or O_RDWR.
The implication is that a lockf() lock is equivalent to an fcntl() write
lock.

As far as implementing fcntl() locks, it isn't all that hard (we used to have
the John Bass lockf() code, and I restructured it to add fcntl() behavior).
Basically, I spent a day drawing pictures of overlapping locks of various
types until I became enlightened.


--
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA

"Soylent Green is People Helping People!"