[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: modify chmod
From: |
Jim Meyering |
Subject: |
Re: modify chmod |
Date: |
Sat, 13 Feb 2010 10:48:43 +0100 |
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?
- Re: modify chmod, (continued)
- Re: modify chmod, jeff.liu, 2010/02/06
- Re: modify chmod, Jim Meyering, 2010/02/06
- Re: modify chmod, jeff.liu, 2010/02/07
- Re: modify chmod, Jim Meyering, 2010/02/07
- Re: modify chmod, jeff.liu, 2010/02/07
- Re: modify chmod, Jim Meyering, 2010/02/07
- Re: modify chmod, jeff.liu, 2010/02/08
- Re: modify chmod, jeff.liu, 2010/02/08
- Re: modify chmod,
Jim Meyering <=
- Re: modify chmod, jeff.liu, 2010/02/21
- Re: modify chmod, Jim Meyering, 2010/02/21
- Message not available
- Re: modify chmod, Jim Meyering, 2010/02/21
- Re: modify chmod, jeff.liu, 2010/02/21
Re: modify chmod, jeff.liu, 2010/02/05