On Tue, 20 Oct 1998, Jonathan Stone wrote:

: Ack. pfft.  If you _have_ to do this, despite what kre says,

Honest, I'm not trying to fight with Robert ... a "different interpretation"
of group quotas is only one aspect of changing the way a new inode's gid is
determined.

: make it a mount option (so it applies per filesystem), not a sysctl.
: Otherwise the quota  interactions  are just _horrible_.

I personally use it now on all my filesystems, including those with quotas.  
I _wanted_ the "different" quota behavior.  ;)

Anyway, that's a good suggestion (making it a mount option).

: EGID is backwards.  I'd use "dirgid" or "grpid" (wasnt that what SunOS
: used?) but make the default be whatever POSIX says, if that's
: different from BSD practice, and BSD otherwise.

It uses the componentname ucred gid, whch is the user's egid.  POSIX
specifies "...the file's group ID shall be set to the group ID of the
directory in which the file is being created or to the effective group ID of
the process." [ISO 9945-1:1996, 5.3.1.2, 215-217]  Same goes for directories
and special files (the latter of which my patches did _not_ change).

This means that any of SVR4, BSD, or my (SVR4 if user is not a member of the
directory's group, BSD if the user is a member) behavior are legal.

: If we go down this route, I dont see why it shouldn't apply to all
: local filesystems that have group-IDs.

I'd agree there.

:  I dunno about nonlocal (NFS,...) though : if the client's mount flags
: disagree with the server's local mount flags, who should win?

This should be left to whichever side has control over the initial gid of an
inode.  I don't know which has that control; if it's the client, then we
should have same in the NFS client code, and if server, the local fs mount
will determine that.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)