On Fri, Dec 07, 2001 at 12:58:31AM +1100, Cameron Simpson wrote: ... > Not so. The sunos4 boxen don't have lchown()
You're right. However, the chown man page says it doesn't follow symlinks: If the final component of path is a symbolic link, the own- ership and group of the symbolic link is changed, not the ownership and group of the file or directory to which it points. > and I'd expect the orignal > BSD stuff where symlinks came in didn't have it. (I certainly had never > tripped over it). I don't have any other BSD systems, but I would think they'd be like Sunos4. > Another counter example - Apollo symlinks were special directory entries, > not objects with inodes, and chowning them was meaningless. SInce the > target permissions were always enough anyway (permissions on a symlinks > can be trivially bypassed by opening the full path, and symlinks are > not writable themself - only creatable), so inodeless implementations > are both feasible and sensible. Does anybody run rsync on Apollo? > Please - if there's no lchown DO NOT chown symlinks. It is silently > destructive. I say let's don't bother to change it unless somebody reports a problem. > <RANT> > It has long offended me that the default chown/chgrp/chmod calls follow links > - to my mind the _only_ system calls that should follow links are open() and > chdir(). It would have made for a much saner and safer world. > </RANT> Looks like the BSD inventors of symlinks agreed with you for chown & chgrp (but not chmod). Only SystemV messed up when they added symlinks, and as a result had to come up with lchown. - Dave Dykstra