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.