[comp.unix.wizards] lockf

rick@seismo.CSS.GOV (Rick Adams) (03/18/87)

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?

---rick

dss%fatkid@Sun.COM (Daniel Steinberg) (03/19/87)

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)

gwyn@brl-smoke.UUCP (03/21/87)

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()?

The general answer is, yes.  lockf() was specified in the 1984
/usr/group Standard, and was derived from John Bass's implementation
found in some pre-System V UNIX or UNIX-like systems.  fcntl()
locking appeared slightly after SVR2.0.  Unfortunately IEEE 1003.1
has not yet to my knowledge replaced lockf() with the fcntl()
approach (which I find much superior).

craigb@ipso.OZ (Craig Bevins) (04/24/87)

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()?

Yes - Venix System V from release 2.2 on.

Craig.
-- 

Craig Bevins.
IPS Radio and Space Services.  Sydney, Australia.

ACSnet: craigb@ipso			CSNET:	craigb@ipso.oz
ARPA:	craigb%ipso.oz@seismo.css.gov	JANET:  ipso.oz!craigb@ukc
UUCP:	{enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!ipso.oz!craigb