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

[Guy Harris]

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