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

[Jonathan S. Shapiro]

In article <1988Nov26.220052.19423 at ateng.ateng.com> chip at ateng.ateng.com (Chip Salzenberg) writes:
>
>...and unfortunately, despite all protestations to the contrary, SCO Xenix
>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.

Actually, if you read the fine print in the SVID, you may discover
that they are conforming, and that even if they aren't, your claim
about conforming programs is not quite on target.

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.

In SVR3, the locking became mandatory.

If SCO Xenix is SVR2-based, then it would appear that they are not
SVID conforming in this regard.  If they are SVR3-based then they are
conforming.  I don't know enough about the product to know one way or
the other.

One might even argue that by implementing the warning ahead of
schedule they are still SVID conforming, even under SVR2.

However, a program written to conform to the SVID will have no
problems in either case, because the warning in the SVID commentary
indicates that your program should make pessimistic assumptions about
deadlock.

Jonathan S. Shapiro
AT&T Bell Laboratories