I was in the middle of a lengthy reply to this, which I've abandoned, as it
can pretty much be summarized as "If you don't want this behavior, don't
enable it."

It wouldn't be the default, and if you didn't want it, you wouldn't enable
it. Perhaps it might be enabled on some system you inherit, but in that
case whoever originally turned it on must have wanted it. So you'd change
it to suit your needs. There's *lotso* stuff on a hand-me-down system
that's probably not configured the way you want :).

I'm not trying to force a particular behavior on anybody. I just want an
optional behavior available to meet the specific needs of my deployment.


On Fri, 26 Feb 2010, David Dyer-Bennet wrote:

> The problem with that, of course, is that it's equally true in a
> pure-permissions world -- if I'm trying to change the permissions with
> chmod, it's safe to assume that the new values aren't what the person
> who originally configured the protections on that file wanted.  THAT'S
> WHY I'M CHANGING THEM!
>
> So I don't see how that's a great argument for ignoring what I do.
[...]
> Okay, but the argument goes the other way just as well -- when I run
> "chmod 6400 foobar", I want the permissions set that specific way, and I
> don't want some magic background feature blocking me.  Particulary if
> "I" am a complex system of scripts that wasn't even written locally.

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to