Xref: utzoo comp.unix.questions:10376 comp.unix.wizards:12953 Newsgroups: comp.unix.questions,comp.unix.wizards Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: what is the 'l' permission? Message-ID: <1988Nov29.193157.24982@utzoo.uucp> Organization: U of Toronto Zoology References: <71@attibr.UUCP> <4594@ptsfa.PacBell.COM> <483@auspex.UUCP> <4945@b-tech.ann-arbor.mi.us> <951@vsi.COM> <1988Nov25.213310.11511@utzoo.uucp> <516@auspex.UUCP> Date: Tue, 29 Nov 88 19:31:57 GMT In article <516@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >>Consider a program that mandatory-locks /etc/passwd and then sleeps forever. >>... >Well, actually, in order to lock out reads, you have to establish a >write lock on the region in question, and to establish a write lock you >need to have a file descriptor open for writing... Hmm, guess I should have read the documentation! :-) At at least one point in the past, for at least one of the locking schemes (/usr/group?), locking /etc/passwd *was* a problem and hence the 'l' bit. >In AT&T's documentation, they appear to recommend that you not use >mandatory locking because there's extra overhead on every read or write >performed... One can always argue that a more efficient implementation could largely fix this. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu