On Sun, Dec 02, 2001 at 11:52:08PM +1100, Martin Pool wrote: > I see rsync has this in rsync.h > > #ifndef HAVE_LCHOWN > #define lchown chown > #endif > > So on Linux lchown changes the ownership on a symlink, whereas chown > on a symlink will change the ownership of its target. man lchown says > > In versions of Linux prior to 2.1.81 (and distinct from > 2.1.46), chown did not follow symbolic links. Since Linux > 2.1.81, chown does follow symbolic links, and there is a > new system call lchown that does not follow symbolic > links. Since Linux 2.1.86, this new call (that has the > same semantics as the old chown) has got the same syscall > number, and chown got the newly introduced number. > > I'm not at all sure the way we're calling it is correct. There could > be systems where there is no lchown, but chown on a symlink still > follows the link. I seem to remember Solaris behaving this way, but > I'm not sure if that is the system call or just the chown command. > > In this case we might be accidentally setting the ownership of the > destination. On such a machine we should just not set the ownership > of the symlink at all. (To be really tricky I guess we could > seteuid() before creating the link.) > > David, do you have a machine that behaves like this?
No, I don't. Even my oldest systems have symbolic links and also have lchown. I think any system that has symbolic links would have to implement the lchown/chown distinction, so I don't think it's something to worry about. - Dave Dykstra