chip@ateng.ateng.com (Chip Salzenberg) (11/27/88)
[Followups directed to comp.unix.xenix; you'll see why.] According to guy@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 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. Sigh. I tested it on SCO Xenix/286 2.2.1. It's true. I wish it weren't. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (11/29/88)
In article <1988Nov26.220052.19423@ateng.ateng.com> chip@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
guy@auspex.UUCP (Guy Harris) (11/30/88)
>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.