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