Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Mandatory locking (was Re: the 'l' permission)
Keywords: mandatory locking; Xenix seems broken
Message-ID: <537@auspex.UUCP>
Date: 29 Nov 88 19:48:33 GMT
References: <71@attibr.UUCP> <4594@ptsfa.PacBell.COM> <483@auspex.UUCP> <1988Nov26.220052.19423@ateng.ateng.com> <5317@polya.Stanford.EDU>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 40

>In SVR2, advisory locking was introduced via lockf(2) and fcntl(2).  A
>reading of the fine print will turn up a note indicating that this
>will be changed to be mandatory locking at some unspecified point in
>the future.

More precisely, what it says is:

	Enforcement-mode file-locking and record locking will be added:

	   *If enforcement-mode file and record-locking is set* and
	   there are outstanding record locks on the file, this may
	   affect future calls to READ(BA_OS) and WRITE(BA_OS) routines
	   on the file [see CHMOD(BA_OS)].

And CHMOD(BA_OS) says:

	Enforement-mode file and record-locking will be added:

	   If the mode bit 02000 (set group-ID on executeion) is set and
	   the mode bit 01000 (execute or search by group) is not set,
	   enforcement-mode file and record-locking will exist on an
	   ordinary-file.  This may affect future calls to...

>In SVR3, the locking became mandatory.

More precisely, in S5R3 the locking becomes mandatory *if* the
permission bits are set as specified.  S5R3, fortunately, does not shove
mandatory locking down your throat.  However...

>If they are SVR3-based then they are conforming.

as I read what the original poster said, Xenix *does* shove mandatory
locking down your throat, which is NOT SVID-conforming.

>However, a program written to conform to the SVID will have no
>problems in either case,

Wrongo.  A program that expects locks to be mandatory only if the
set-GID bit is set and the group-execute bit is not set could be in for
a real surprise.