Newsgroups: comp.unix.questions
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Subject: Re: Truncating an existing file (and lockf question)
Message-ID: <1991Apr24.214519.24261@athena.mit.edu>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
References: <3172@dsacg3.dsac.dla.mil> <16836@chaph.usc.edu>
Distribution: usa
Date: Wed, 24 Apr 91 21:45:19 GMT
Lines: 26

In article <16836@chaph.usc.edu>, jeenglis@alcor.usc.edu (Joe English) writes:
|>      A shared or exclusive lock is either advisory  or  mandatory
|>      depending on the mode bits of the file containing the locked
|>      segment.  The lock is mandatory if the set-GID bit (S_ISGID)
|>      is  set  and  the  group execute bit (S_IXGRP) is clear (see
|>      stat(2V) for information about mode bits).   Otherwise,  the
|>      lock is advisory.
|> 
|> This sounds really weird.  Why should locking behaviour depend 
|> on the setgid bit?   Is this just a SunOS quirk?

  They're simply using the S_ISGID bit to store additional information, when
it isn't being used to indicate a setgid executable.  Notice that it only
indicates mandatory locks when the group-executable bit isn't set.  This means
that it has nothing to do with locking when the file *is* group-executable;
instead, it takes on its traditionaal task of indicating a setgid executable.

  Overloading of permission bits has become somewhat common as people find
more and more information that needs to be stored.  For example, the use of
the sticky bit to indicate sticky directories is a somewhat late addition.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710