lkml.org 
[lkml]   [1996]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: How does chown(2) works with symlinks?
On Mon, 8 Jul 1996 Mark.Hemment@uniplex.co.uk wrote:

> > I think some older versions of linux actually changed the file that the
> > symlink pointed to, and it got changed at one point. I could be mistaken,
> > though,
>
> This behaviour is incompatible with most (all?) other versions of
> UNIX I've used - SVR4 derived, and Solaris.
>
> The chown(2) syscall should follow the link(s). The OS provides another
> call, lchown(2), for operating directly on a symlink (some also
> provide a lchmod(2), such as SCO's OpenServer). There is also a
> lstat(2).
>
> I believe the latest POSIX drafts have tackled symbolic links (they
> worked around the issue before). It would be nice to known what
> they say...

I don't know what POSIX has to say about this, but it is interesting
to read what Stevens says about this:

"The lchown function is unique to SVR4. Under non-SVR4 systems (POSIX.1
and 4.3+BSD), if the pathname for chown is a symbolic link then the
ownership of the symbolic link is changed, not the ownership of the file
referenced by the symbolic link. To change the ownership of the
file referenced by the symlink we have to speify the pathname of the
actual file itself, not the pathname of a symlink that point to a file."

Some people on this list already gave some convincing arguments that this
is a Good Thing.

Johan Myreen
jem@iki.fi




\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.120 / U:1.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site