On Aug 4, 10:24am, James Graham (Captech) wrote:
} Subject: Re: Symlink ownership
} Since times on a symlink are not necessary and don't change (unless you 
} implement them as per der Mouse's suggestion), lutimes() becomes unnecessary.
} Since modes on a symlink are not necessary and don't change (unless as
} previously mentioned), lchmod() becomes unnecessary.  The only confusion that 
} I have is that chmod() affects the target while chown() affects the link,
} but it's been this way for ages, and if we change it so that lchown() affects
} the link, this will break existing code.

I don't really have a problem with changing chown() so that it affects
the target.  This change would be compatible with between systems with
ownerful and and ownerless symlinks.  I suspect the amount of code broken
by this change would be minimal.  If chown() is changed, then systems
with ownerful symlinks need lchown() to set the link owners.  Code that
is portable to any POSIX systems just needs to ignore the st_uid returned
for symlinks and can't call lchown() (which should not be declared in
<unistd.h>).  I put timestamps on symlinks in the category of
administrative convenience, so it would be nice if lutimes() existed
as well, so that if you dump a filesystem, newfs, and restore, you get
the same thing back as you started with.  I don't think dump and restore
have any hope of being portable to any POSIX compliant system, so it
shouldn't matter if restore calls lchown() and lutimes().

If we have to eliminate symlink owners in order to POSIX compliant, then
do we have to eliminate Unix domain sockets as well?

} An alternative would be to have chown()/chmod()/utimes() (as necessary; 
} currently the only problem seems to be with chown()) have an extra argument
} at the end:  u_int nofollow, which, if set, would (*func)() the link in-
} stead of the object.

This change would break all existing code that uses these syscalls.
All the calls would have to be tweaked to add the extra argument.


			---  Truck