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 e...@byu.net
signature.asc
Description: OpenPGP digital signature