Differential D2316
Standardise chmod, chflags and chown option processing Authored by smh on Apr 17 2015, 5:33 PM. Tags None Referenced Files
Details chmod, chflags and chown had sligntly different:
This standardises all three on:
Diff Detail
Event Timeline
Comment Actions If you're changing this, please make the interaction between -h and -R more sensible, as specified by symlink(7) and POSIX (though in the latter case not for chmod and chflags). In that interpretation, it is never necessary to specify -h with -R; instead, -P implies -h, and -H implies -h for those files listed on the command line (not found in the tree walk). This may not be a fully compatible change, but it fixes confusing behaviour that commands like "chown -R u:g tree" leave symlinks alone. For compatibility, chown will still have to allow -RPh but all other -Rh were not allowed and therefore do not need to be allowed.
Comment Actions Thanks for looking at this, I'm a little confused by your statement about "-H implies -h" as it seems to contradict symlink(7) specifically: How I interpret that is that -H disables -h behaviour for the files specified on the command line only as they should already be dereferenced. This would mean the combination of atflags AT_SYMLINK_NOFOLLOW and fts_options FTS_COMFOLLOW would achieve the desired behaviour. Similarly when -L is specified the use fts_options FTS_LOGICAL would produce the desired behaviour (no symlinks will be affected on the files / directories the link to) as all entries will be dereferenced.. If my interpretation is correct I believe the following should achieve the desired behaviour in all cases: if (Rflag) {
// Recursive
if (Lflag) {
// Symlinks not effected.
fts_options = FTS_LOGICAL;
} else {
// Symlinks effected
fts_options = FTS_PHYSICAL;
atflag = AT_SYMLINK_NOFOLLOW;
if (Hflag) {
// Symlinks on the command
// line not effected.
fts_options |= FTS_COMFOLLOW;
}
}
} else if (hflag) {
// None Recursive
// Symlinks effected.
fts_options = FTS_PHYSICAL;
atflag = AT_SYMLINK_NOFOLLOW;
} else {
// None Recursive.
// Symlinks not effected.
fts_options = FTS_LOGICAL;
}
Comment Actions Oh right, I should have said -H implies -h for those files found in the tree walk.
You can't use a common atflag for all files, since for -H, you need to do something different for files specified on the command line (fts_level == FTS_ROOTLEVEL) and files found in the tree walk. It is a bit unfortunate that some part of fts(3) functionality (the decision AT_SYMLINK_NOFOLLOW or 0) needs to be replicated here. I think the following would work, placed in the fts_read loop (untested): if (Rflag) atflag = Lflag || (Hflag && p->fts_level == FTS_ROOTLEVEL) ? 0 : AT_SYMLINK_NOFOLLOW; else atflag = hflag ? AT_SYMLINK_NOFOLLOW : 0; error = fchmodat(AT_FDCWD, p->fts_accpath, newmode, atflag); It would be simpler to use AT_SYMLINK_NOFOLLOW iff fts_info == FTS_SL || fts_info == FTS_SLNONE but this is wrong since the utilities must not follow symlinks if they were requested not to, even if someone races replacing a non-symlink with a symlink. Comment Actions ... Seems FTS_COMFOLLOW is not as straight forward as it sounds, in that it appears to return the fts_info for the followed link but the rest of the details in the FTSENT are from the link itself, which seems very odd given its description and the description of FTS_LOGICAL: FTS_COMFOLLOW This option causes any symbolic link specified as a root path to be followed immediately whether or not FTS_LOGICAL is also specified. FTS_LOGICAL This option causes the fts routines to return FTSENT structures for the targets of symbolic links instead of the symbolic links themselves. If this option is set, the only symbolic links for which FTSENT structures are returned to the application are those referencing non-existent files. Either FTS_LOGICAL or FTS_PHYSICAL must be provided to the fts_open() function. I will research some more... Comment Actions Switch recursive processing to match that described in symlink(7) as per jilles@ feedback. It should be noted that atflags needs to be calculated for each file returned from fts_read as contrary to the current version of FTS(3), only certain fields e.g. fts_info and fts_statp of the returned FTSENT structure reflect the dereferenced symlink entries when doing logical structure traversal as indicated by FTS_COMFOLLOW or FTS_LOGICAL. This also makes use of fchownat, fchmodat and chflagsat instead of using function pointers to make it easier to follow. I've ammended the man pages slightly to refect the changes but would welcome feedback specifically in this area. Comment Actions I've created a little test script to help verify the new behaviour, for those interested it can be found here: Comment Actions I have some small remarks that apply to all three but I only wrote them in chflags. chown correctly differs from the others in that it accepts -h with -R (but it now does nothing). The commit should have Relnotes: yes and some hints should be provided for the release notes, like "chflags, chgrp, chmod and chown now affect symlinks in -RP mode; formerly, symlinks were silently ignored".
Comment Actions -R implies -h now so I don't believe it needs to do anything different from its standard processing.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||