Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!styx!ames!ucbcad!ucbvax!hplabs!decwrl!sun!fatkid!dss
From: dss%fatkid@Sun.COM (Daniel Steinberg)
Newsgroups: comp.unix.wizards
Subject: Re: lockf() without fcntl interface?
Message-ID: <15291@sun.uucp>
Date: Wed, 18-Mar-87 22:41:41 EST
Article-I.D.: sun.15291
Posted: Wed Mar 18 22:41:41 1987
Date-Received: Sat, 21-Mar-87 03:46:56 EST
References: <43167@beno.seismo.CSS.GOV>
Sender: news@sun.uucp
Reply-To: dss@sun.UUCP (Daniel Steinberg)
Organization: Sun Microsystems, Mountain View
Lines: 45
Keywords: lockf, fcntl, flock

In article <43167@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes:
>Are there any unix implementations that offer a SVID lockf() compatible
>file locking that do NOT also support the same locking via fcntl()?
>
>I.e. if I do
>	fcntl(fd,F_SETLK,&flockstruct)
>where
>flockstruct specifies a l_type of F_RDLCK, will it NOT work on a system
>that supports the flock() call?
>

Hmmm, well if you *REALLY* meant 'flock()' in that last line, then
the answer is certainly:
    Yes...many BSD-based systems offer flock() semantics but not
    lockf() nor locking via fcntl().

However, assuming that you meant 'lockf()', then the answer is:
    Yes...anybody that implemented lockf() using the /usr/group
    standard and/or John Bass' published kernel modifications could
    very well have implemented lockf() without the SVID-compatible
    fcntl() locking.  I have heard that such implementations exist.

Note, also, that the current draft of the IEEE P1003.1 Portable
Operating System Standard (POSIX) does NOT include fcntl() locking
semantics, but it DOES define a lockf() function that is similar
(but not identical) to the SVID lockf().  Points of difference include:

	* SVID requires that the file descriptor is open with
	  write permission in order to set a lock.  POSIX does
	  not have such a restriction.

	* SVID specifies that EACCES is returned if an attempt
	  to test-and-set a lock fails because the section is
	  already locked by another process.  POSIX specifies
	  EAGAIN for this condition.  SVID notes EAGAIN as a
	  "Future Direction".

	* SVID Issue 2 Volume III specifies lockf() as an interface
	  for Advisory and Mandatory Locking.  POSIX lockf() is
	  Advisory only.

POSIX is not cast in concrete (yet) so some of the above may change
[some of us would like to see locking taken out of POSIX altogether].

-daniel  (ucbvax!sun!dss)