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