Messages in this thread | | | Date | Sat, 28 Dec 1996 11:58:44 +0000 (GMT) | From | Mark Hemment <> | Subject | Re: link(2) creates hard link to symlink in some cases |
| |
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
| |