On Sun, Mar 13, 2016 at 9:11 PM, Michael McConville <[email protected]> wrote:
> It seems that chown(1) will write to a file even if it already has the
> desired ownership. The below patch causes it to skip the write when
> there would be no change. The best I could tell, the fts_read(3) and
> fchownat(3) logic agree on whether to follow symlinks in all cases, so
> there's no need to execute a useless write when certain options are
> specified.
Regretfully, I don't think this can be the default behavior. There
are filesystems where you can't whether chown() would be a no-op from
just checking the uid/gid, as the syscall may affect permission bits
or ACLs. For example, an apparent no-op chown() will clear the
setuid/setgid bits. (While we don't have ACLs on any native
filesystems, they may be accessible via NFS or fuse.)
I think that sort of complexity is why POSIX specifies that chown(8)
has the effect of calling chown(2) on each target, without leaving
room for skipping what might appear to be no-ops.
The existing solution for the problem of saving time when you really
are sure there's no magic bits to be changed is to use find to hunt
out the files that need it, ala
find . ! -group www -exec chgrp -h www {} +
or even script it...
fast_chgrp() { local grp=$1; shift; find "$@" ! -group $grp -exec
chgrp -h $grp {} +; }
Philip Guenther
