BUG with g+s: Re: "Inherit Permissions" request for comments

[Michael Tokarev]

David Collier-Brown wrote:
> 
> Michael Tokarev wrote:
> >                                 In the other words,
> > inherit permissions parameter changed semantics of g+s when unset.
> > If this is considered normal, than it should be documented as
> > compatibility change (that is, 2.0.7 is incompatible with all previous
> > versions on this respect).
> 
>         "Erk", saith the tech writer! (;-))
> 
>         Seriously, though, once we decide upon a resolution,
>         I'll propose a migration strategy to this list and a
>         documentation change to the docs list.

Just a thought -- this particular change:

  Cope with UNIXes that don't allow high order mode bits on mkdir.
  Patch from gcarter at lanier.com.

Is it will be better to test if particular system does not support
high order mode bits in mkdir with autoconf and do _not_ use chmod
if it supports them?  It will improve things a bit...

But one more thing -- BSD semantics is a bit different than posix
ones in g+s respect.  BSD, as I know of, always inherits group from
parent dir, so g+s is simple unnecessary there (correct me if I'm
wrong, I have no BSD around).  And with this (gid is inherited), would
it be "better" to issue chgrp/chown call after creation of file/directory!?
With current approach with chmod, seemed to be logical at least... :)
Maybe samba will be another OS with it's own permissions, owners, groups
etc and own rules on all this, owerriding underlying OS's (good) work??!
This all is like an argument for my previous message. :)

While on unix, I never have a trouble with setting file permissions/groups/etc.
Why the samba "layer" introduces new things that can be avoided on
plain unix?  Is is will be better to just implement chmod/chgrp/chetc
ability (using maybe NT's ACL dialogs or something on samba's own way)?

Regards,
  Michael.