Date: Sun, 3 May 1998 22:06:54 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@FreeBSD.ORG, helbig@Informatik.BA-Stuttgart.DE Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-usrsbin@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/chown chown.c Message-ID: <199805031206.WAA20229@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> The previous commit broke this. The first victim was bsd.prog.mk, >> which uses a plain chown in an attempt to change the ownership of the >> symlinks to `dm' in /usr/games. This fails when it is done before >> dm is installed, or messes up the ownership of dm if dm is installed. > >Before and after r1.11 it always failes, since symlinks were ignored >completely by chown(8) without [-hHL], i. e. neither the symbolic >link nor the file linked to were affected by chown(8). Ignoring is not quite the same as failing. When symlinks didn't have owners, it was correct to ignore the chown(8), since following the link might have clobbered the owner of the target. Both following the link and ignoring the chown(8) are harmless in /usr/games, provided the target exists (the symlink targets are already owned by games.bin, and it just makes `ls -l' output look nicer to change the symlink ownership from root.bin to games.bin). >I suggest to implement the 4.4BSD behaviour as outlined in symlink(7), >and documented in the man page of chown(8). I suggest not. The 3 commands documented as following symlinks specified on the command line (chown, chgrp and file(1)), seem to have never actually done that in FreeBSD: 4.4Lite's file.1 documents doing it, but 4.4Lite is missing the source for /usr/src/usr.bin/file. It only has sources for contrib/file-3.12, which don't do it, at least when naively configured. Anyway, we blew away 4.4Lite's file.1 with a newer distribution of `file' which has a -L option like ls's. 4.4Lite's chown.8 conflicts with its symlink.7. The former says that "Symbolic links don't have owners, so unless the -H or -L option is set, chown on a symbolic link always succeeds and has no effect". Similarly for 4.4Lite's chgrp.1. >Let cslink and rslink be symbolic links pointing to the files >cpointed_to and rpointed_to respectively. Assume cslink be >given on the command line and rslink found during a recursive >traversal. > >flags affected >--------------------------------- > cpointed_to >-h cslink, >-R cslink, rslink >-RH cpointed_to, rslink >-RL cpointed_to, rpointed_to OK, this is what rev.1.10 does (except for -R). >The -h option gives complete control in the nonrecursive case, and >the -R[HL] options in the recursive case, if implemented as outlined above. I think -HLP should have applied without -R: -H cpointed_to -L cpointed_to (same as -H; already implemented in ls(1) and file(1)) -P cslink (same as default) -h cslink (same as default, deprecated) >> 2. If we implement the historical behaviour, then -h would become a no-op >> and should be left undocumented. > >But then at least symlink(7) should be changed to reflect this. Yes. >> 4. The correct interaction of -h with the other flags is not clear. > >According to symlink(7) -h and -R[HL] cannot be given together on >the command line. I can't find this. >If you agree, I'd implement the 4.4BSD suggestions (r1.11 didn't, >with -R alone the pointed to files were affected instead of the >symlinks themselves). -R actually ignores symlinks deep in the tree as well as on the command line. It should handle all symlinks the same (only the -H flag give different handling of symlinks on the command line). I think it should change the symlinks (NOT as in symlink.7). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805031206.WAA20229>