Date: Sun, 3 May 1998 11:48:53 +0200 (MET DST) From: Wolfgang Helbig <helbig@Informatik.BA-Stuttgart.DE> To: bde@FreeBSD.ORG (Bruce Evans) Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-usrsbin@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/chown chown.c Message-ID: <199805030948.LAA01172@rvc1.informatik.ba-stuttgart.de> In-Reply-To: <199805030417.VAA21679@freefall.freebsd.org> from Bruce Evans at "May 2, 98 09:17:53 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> bde 1998/05/02 21:17:53 PDT > > Modified files: > usr.sbin/chown chown.c > Log: > Backed out previous commit. chown(8) doesn't follow symlinks by > default, at least in BSD. This used to be automatic, because chown(2) > didn't follow symlinks. When chown(2) was changed to follow symlinks > in BSD4.4, chown(8) was changed to not follow symlinks by default. > 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). I suggest to implement the 4.4BSD behaviour as outlined in symlink(7), and documented in the man page of chown(8). 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 > Unfixed problems: > 1. When lchown(2) was implemented, chown(8) wasn't changed to implement > the historical behaviour of changing ownership of symlinks. I'm not > sure if it should have been. The -HLP options give more complete > control, but they unfortunately don't apply unless the -R option is > specified (a problem shared with other commands, e.g., cp; I guess > we're supposed to use -R even for non-recursive traversals). The -h option gives complete control in the nonrecursive case, and the -R[HL] options in the recursive case, if implemented as outlined above. > 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. > 3. The man page suggests that without option -h, all symlinks (to files > specified in the command line?) are followed. It's not clear what > "the file" is. These bugs were introduced when -h was documented. ``the file'' is the one given on the command line. > 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. 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). Wolfgang > Revision Changes Path > 1.12 +2 -1 src/usr.sbin/chown/chown.c 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?199805030948.LAA01172>