Re: modify chmod

[Jim Meyering]

jeff.liu wrote:
> jeff.liu 写道:
>> Jim Meyering 写道:
>>> Finally, I see the one true way ;-)
>>> Do this for each "name":
>>>
>>>     - open each file/dir. with fd = openat (fts_cwd_fd, name, ...
>>>     - if that succeeds, then call fstatfs (fd, ...
>>>
>>> Using the combination of openat and fstatfs is required in order to
>>> avoid using the full relative name of each object that chmod processes.
>>>
>>> The above works for all readable objects.
>>> For unreadable ones, revert to using the statfs with the full relative name.
>>>
>>
>> Thanks for the hints.
>>
>> But according to my tryout, it looks we can not gain performance benefits in 
>> this way. :(
>> calling openat() could cause a bits overhead as well.
>>
>
> I also tried to pass over the openat(), instead just comparing the fts_cwd_fd 
> againt AT_FDCWD,

Hi Jeff,

Skipping the openat call and thus operating on the full relative
file name is not an option, since that will always fail when its length
is longer than PATH_MAX.
Hence, you must use openat.  However, if[*] we agree not to worry about
bind-mounted non-directories, you should still be able to use openat
without prohibitive overhead.

You would maintain at least a single static pair {FD,val}
indicating whether FD may_have_nfsacl (yes, no, do-not-know).
Then you'd incur the cost of an openat call only for command-line
arguments (where fd is AT_FDCWD), and when a traversal transitions
from one directory to another.

The approach (mentioned initially) taken by fts.c is to record
not just the single {FD,val} pair, but a set of {stat.st_dev,val}
pairs, one for each distinct device encountered.  This requires
a small amount of extra overhead (time and memory), but reduces
the number of *statfs calls to the bare minimum.

[*] 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?