DragonFly commits List (threaded) for 2008-11
Re: cvs commit: src/usr.bin/chflags chflags.c
:Well I expected chflags's behavior to be like chown -- that is, if I
:chflags a symlink, I expect it to do the operation on the underlying
:file, just like chown would do. To operate on the actual symlink, I'm
:going to add a -h option to chflags which will use the new lchflags
:I don't think my assumption or expectations are out of line. Otherwise,
:there's no way to do any chflags ops through a symlink.
Here's the problem.
userA: ln -s /root/.cshrc .cshrc
root: cd ~userA; chown userA .cshrc
In otherwords, when the behavior operates like this, the chances of
a common mistake creating a very serious issue in the system becomes
If you have a softlink to a directory and specify it on the command
line you wind up in even more trouble.
In another example, having the operation work differently for recursive
operations verses non-recursive operations is very bad. Clearly this
cannot be the default (and it isn't) for recursive operations or you
can wind up destroying the permissions or ownership of your entire
system if someone happens to softlink /. But having the behavior work
differently whether -R is specified or not is just not a good idea.
Thus it cannot run through the softlink for either operation.
It is very, very easy for a system administrator to shoot himself in
the foot if these commands operate through softlinks by default.
I really do not want any of these programs going through the symlink
by default, particularly if we have the tools to actually control
the ownership, modes, and flags of the link itself.