Re: modify chmod

[jeff.liu]

Jim Meyering 写道:
> jeff.liu wrote:
>
>   
> > Jim Meyering 写道:
> >     
> > > jeff.liu wrote:
> > >
> > >       
> > > > A tiny patch, make chmod do not touch the inode if the new file
> > > > permission mode is same as it was before.
> > > >
> > > >         
> > > ...
> > >
> > >       
> > > > +static bool
> > > > +may_have_nfsacl(const char *file)
> > > > +{
> > > > +# if HAVE_SYS_VFS_H && HAVE_SYS_STATFS_H && HAVE_STRUCT_STATFS_F_TYPE
> > > > + struct statfs buf;
> > > > +
> > > > + /* If statfs fails, assume we can't use the optimization. */
> > > > + if (statfs (file, &buf) < 0)
> > > >
> > > >         
> > > This function should accept a file descriptor, not a file name,
> > > and should call fstatfs, not statfs.
> > >
> > >
> > >       
> > Thanks for the correction.
> > IMHO, to get a fd, then call fstatfs ranther than statfs here, is to
> > ensure the same file object proceeding to operated on?
> >     
>
> fts provides a file descriptor for every directory it processes,
> so you can use an "FTS_ENT const *ent" parameter instead.
> When it refers to a directory, use ent->fts_fts->fts_cwd_fd as the
> file descriptor.  Otherwise, you will have to call statfs after all.
>   
thanks for the point out.
Actually, by consulting your primary comments for using fstatfs(2),
I was also thought the only way is pass the fts_cwd_fd to it,
then I started to study the fts_xxxx() series functions and added debugging
instruments to check the fts_cwd_fd value againt a five-depth directory.
but at that time, I found many -100(AT_FDCWD) printed out somehow.
so I took it for granted to call statfs since it can save the time if do not
need to check the fts_cwd_fd against AT_FDCWD frequently.
> At first, I was thinking we could avoid statfs most of the time (i.e.,
> change device only at a directory), but with bind-mounted regular files,
> the device can change at any time during a traversal.
>
>
>