Re: modify chmod

[Eric Blake]

According to Jim Meyering on 1/30/2010 8:50 AM:
>> Does it make sense to make chmod do not change the inode's ctime
>> if the new permission bits is identical to the old as the default behavior?

I still think POSIX allows it.  Rather than calling out chmod(2) behavior,
POSIX states that for chmod(1):

"Upon successfully changing the file mode bits of a file, the chmod
utility shall mark for update the last file status change timestamp of the
file."

> With the patch below, it skips the chmodat call altogether, because
> chmod notices that "u+x" would not modify the existing permissions:
> 
>     $ ./chmod u+x /
>     $
> 
> If we were to insist that the modified chmod
> produce the same diagnostic, we *could* try.
> But we'd have to compare effective uid to stat.st_uid, ...
> and what about the possibility of ACLs?  So I think that is
> not an option.
> 
> This new behavior could be useful...
> maybe noticeably more efficient in some cases, too.
> Perhaps worth a new option, if not the default.

I think that optimizing no-op chmod(1) by default is reasonable, but it
would still be nice to have an option to guarantee a chmod(2) call (for
its ACL side-effects, even if the permission bits appear to be a no-op).

> -      if (! S_ISLNK (old_mode))
> +      if ((old_mode & CHMOD_MODE_BITS) == new_mode)

One other thing - I'm still hoping to find some time to work on:

providing a gnulib replacement to work around Solaris 9's bug ('chmod
file/' mistakenly succeeds)

teaching coreutils chmod to use lchmod (and/or
fchmodat(,AT_SYMLINK_NOFOLLOW)) on systems that support it (BSD systems at
the moment), such that we can copy BSD's 'chmod -h' and 'chmod -PR'.

Such a patch would impact the same areas of code as the patch under
discussion in this thread.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden

signature.asc
Description: OpenPGP digital signature