Re: modify chmod

[Jim Meyering]

jeff.liu wrote:
> Jim Meyering wrote:
>> jeff.liu wrote:
>>> Hi Jim,
>>>
>>> Thanks for your so detailed instruction! And sorry for my later response, I 
>>> just back from travel.
>>>
>>> Could you please check my comments inline?
>> ...
>>
>> This is the most important point:
>>
>>>> [*] This change is intended to be an optimization.
>>>> I am leery of letting an optimization change the semantics of a
>>>> program like chmod (which is already very efficient), even if only
>>>> for the unusual case of a bind-mounted ACL-possessing non-directory
>>>> that resides on an NFS-mounted file system.
>>>> Other opinions?
>>
>> Considering that this optimization is possible only
>> if we agree to degrade (even by only a small amount)
>> chmod's correctness, I am inclined to drop it.
>>
> so you means this optimization is acceptable only if we can ignore the 
> correctness for the
> bind-mounted files?
> but you think it is no properly since it will affect the semantics of chmod?

Hi Jeff,

That's right.
If someone measures the performance difference and
we find it compelling enough that we're willing to overlook
the incorrectness with (admittedly rare) bind-mounted ACL-possessing
non-directories, this might be worthwhile -- via a new option.
It must not be the default, since it can constitute a real regression.

Chmod is typically quite fast, even for large hierarchies.
Since the value of the performance improvement is less when
enabled only via an option, it becomes harder to justify
the added complexity.