Messages in this thread |  | | From | Mark.Hemment@uniplex ... | Date | Mon, 8 Jul 96 11:45:16 +0100 | Subject | Re: How does chown(2) works with symlinks? |
| |
zefram wrote: > That does make some sense if one is starting from scratch, but we are > talking about Unix here. lchown(2) generally isn't available.
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
|  |