Re: Follow on patches for uid=/gid= behavior changes

Jeff Layton wrote:
> On Fri, 31 Jul 2009 10:04:07 -0500
> Steve French <[email protected]> wrote:
> 
>> The README update seems ok (although a little long, I didn't see an obvious
>> way to shrink it).   I am not convinced that we want to add the warn about
>> kernel behavior change (may be able to do this in mount.cifs more sensibly,
>> or not change the behavior if users turn out to prefer this way)
>>
> 
> Yeah, that's really my question at this point. Should we change the
> default behavior?

I think yes. As suggested by Andrew in the bugzilla (leave old behavior,
add new options -> let users start using new options -> deprecate old
behavior and your patches are already doing this I think). And yes,
tradionally breaking existing behavior is frowned upon by kernel
community but, perhaps for a good reason.

And I agree with Steve on adding Kernel warning. Do we really need to
add a Kernel warning? Would it be sufficient if we warn in mount.cifs? I
think we normally don't warn user about upcoming changes in dmesg.. (and
user may not look at dmesg for such behavioral changes)

> I think it ultimately makes more sense to not clobber the ownership
> unless it's specifically requested. As my evidence I submit the manpage
> update -- there are more "ifs" and special cases when explaining the
> the option behavior.
> 
> OTOH, it's a lot more effort to change the default. Maybe it's not
> worth it.

This sounds like the correct thing to me.

> Another idea: would it be better to dispense with forceuid/forcegid and
> just add a new default_uid= or default_gid= options to specify what the
> owner should be when one isn't provided (and when uid=/gid= aren't
> specified).

Too many options, wouldn't confuse users more, than helping?

> Given that my first pass at this made everyone unhappy, I'd appreciate
> some feedback.
> 


Thanks,

-- 
Suresh Jayaraman