bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modify chmod


From: jeff.liu
Subject: Re: modify chmod
Date: Sun, 21 Feb 2010 21:23:07 +0800
User-agent: Thunderbird 2.0.0.14 (X11/20080505)

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?

Jim Meyering wrote:
> 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.
Thanks for the point out, this is indeed the safe way to avoid "ENAMETOOLONG".

> 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.
So my understanding is call openat() only if the cwd_fd is AT_FDCWD, then check 
the returned FD by
fstatfs(). if openat() failed due to the dir mount pont changed, we have to 
call statfs() againt the
full relative path.

Otherwise, we could determine the FS type by call fstatfs() against the 
dirfd(cwd_fd) on which the
files resides, it is safe since chmod do not do operation on the symlink files.
of coz, we have to call statfs() again if fstatfs() failed with the same issue 
as I mentioned above.

Am I right?
> 
> 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?
> 


Thanks,
-Jeff





reply via email to

[Prev in Thread] Current Thread [Next in Thread]