Re: link(2) creates hard link to symlink in some cases

Mark Hemment (markhe@nextd.demon.co.uk)
Sat, 28 Dec 1996 11:58:44 +0000 (GMT)


Hi,

On Thu, 26 Dec 1996, Alexander V. Lukyanov wrote:
>> On Sun, 22 Dec 1996, Bruce Perens wrote:
>>> Under 2.0.27, link(2) creates a hard link to a symlink,
>>> but only if the target of the symlink exists. This can't
>>> be the intended behavior.
>>
>> From: Mark Hemment <markhe@nextd.demon.co.uk>
>>> It may have been the intended behaviour, but it's certainly the
>>> wrong
>>> behaviour. I test on both SCO's OpenServer, and UnixWare 2.1.
>>> Both followed the symlink for link(2). Not sure what a BSD
>>> derived system does...
>
> FreeBSD 2.1.5 link() follows symlinks.
> Solaris 2.5 does not.
>

In a recent POSIX draft (P1003.1a/D13 - Nov'96);

B.2.2.2 General Terms

symbolic link: May implementations associate no attributes,
including ownership with symbolic links...[blah]...
Historical implementations were followed when determining which
interfaces should apply to symbolic links. Interfaces that
historically followed symbolic links include chmod(), link()
and utime(). Interfaces that historically do not follow symbolic
links include chown(), lstat(), readlink(), rename(), remove(),
rmdir(), and unlink(). POSIX.1 deviates from historical practice
only in the case of chown(). Because there is no requirement
that there be an association of ownership with symbolic links,
there was no point in requiring an interface to change ownership.
In addition other implementations of symbolic links have modified
chown() to follow symbolic links.
...[blah]...
Several reasons were advanced for requiring that when a symbolic
link is used as the source argument to the link() interface, the
resulting link will apply to the file named by the contents of the
symbolic link rather than the symbolic link itself. This is the
case of historical implementations. This action was prefered, as
it supported the traditional idea of persistence with respect to the
target of a hard link. This decision is appropriate in the light
of a previous decision not to require association of attributes
with symboli links, thereby allowing implementations which do
not use i-nodes. Opposition centered on the lack of symmetry on
the part of the link() and unlink() interface pair with respect to
symbolic links.

End quote.

The last paragraph basically says "follow the link".
Remember, the above is draft only, but I'd be v. surprised if
it changes.

Regards,

markhe