> >It's a strange question anyway - You want a single file to have
> >(suppose 755) in one directory, and some different permissions
> (suppost 700)
> >in some other directory? Then some users could access the file if
> they use
> >path A, but would be denied access to the same file if they used path
> >That's weird.
> >It makes no sense to attempt setting perms on a symlink. The perms
> >determined by the actual file. The symlink is just another name for
> >file itself. If you want to change perms of the file, change the
> perms of
> >the file.
> I think the purpose, at least for Solaris, would be making sure that
> chmod() doesn't follow symlinks. lchmod() used on a symbolic link
> be a no-op.
My point exactly. I'm being bold or brazen or ignorant by saying: There is
no point to do a chmod and not follow symlink. Chmod should always follow
symlinks. That's why it's the default behavior, and that's why it's rare,
strange, or impossible to override that behavior.
zfs-discuss mailing list