Mandatory locking (was Re: the 'l' permission)

[Jonathan Bayer]

In article <1988Nov26.220052.19423 at ateng.ateng.com>, chip at ateng.ateng.com (Chip Salzenberg) writes:
. [Followups directed to comp.unix.xenix; you'll see why.]
. 
. According to guy at auspex.UUCP (Guy Harris):
. >"Mandatory locking" merely means that if you use
. >"fcntl" or "lockf" to lock a region of the file, attempts to write the
. >locked region of the file will block until the lock is released, and
. >if the lock is also supposed to block attempts to read that region, it
. >will do that as well.
. 
. ...and unfortunately, despite all protestations to the contrary, SCO Xenix
r does *not* comply with the SVID on this topic.  Even though it's called
. "Xenix System V."
. 
. Under SCO Xenix, there are three locking methods:
. 
. 	locking(), a Xenix invention
. 	lockf(), per /usr/group and in the SVID
. 	fcntl(), in the SVID
. 
. None, that's right, *none* of these locking methods provides advisory
. locking under SCO Xenix.  Even though fcntl() and lockf() MUST be
. advisory to conform to the SVID.  Instead, we get mandatory locking and,
. therefore, deadlocks on programs written to the SVID.  (I wonder what
. the merged product does?)
. 
. A side effect of this is that all files to be locked -- for reading or
. writing, it doesn't matter -- must be opened with write permissions.


Xenix 2.3 has advisary locking.  Also, the release notes for 2.3
go into more detail as to where Xenix fails to meet SVID specs.

Jonathan Bayer
Intelligent Software Products, Inc.