Just checked five machines here. Four have lchown(2), and chown(2)
follows the symlink;
SunOS 5.4
DGUX 5.4R3.10
SCO OpenServer 5.0
HP-UX B.10.01
(AIX 2 3 doesn't have lchown(2))
> Consequently, if you want chown(1) -R to do something useful, chown(2)
> can't follow the link. Like Linus said, use open(2) and fchown(2) if
> you want that behaviour -- that's the portable way to do it.
Yep, that's portable. But the behaviour of chown(2) with symlinks also
needs to be portable.
Most chown(1)s have a flag, -h (some older BSD systems use -L, I think),
to say if the owner of the symlink is to be changed, or if the link is
followed. -h also affects the operation of -R; links to directories
are not followed if -h is given. (some cp(1)s support both a -R and -r,
one form follows links when recursively coping, the other doesn't).
I known some of the later POSIX drafts have started to define the
behaviour of utilites with symlinks (but it's over a year ago since
I had the opportunity to look). They seemed to be making it v.
configurable (an option to say if an operation is performed on the link
or the file it references, and another option to define the behaviour
for recursion), but this is the kernel (not util) list...
Regards,
markhe