Subject: kern/17411: link(2) changed behavior majorly wrt symlinks in 1.5
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 06/27/2002 11:11:35
>Synopsis: link(2) changed behavior majorly wrt symlinks in 1.5
>Arrival-Date: Thu Jun 27 08:06:02 PDT 2002
>Originator: Todd Vierling
>Release: NetBSD 1.5 (or later, including 1.6)
duh.org: Pointing out the obvious since 1994.
Prior to 1.5, link(2) to a symlink produced a hardlink to the pointed-to
file. This corresponds with the behavior in Solaris/x86 2.8 and RedHat
I expected the prior behavior when designing a hardlink-based file
manipulation script for the 1.6 autobuilds, and was caught rather off
guard when symlinks pointing to nowhere were created instead of hardlinks.
$ touch x
$ ln -s x y
$ ln y z # or "link y z"
$ ls -l z
lrwxr-xr-x 2 user group [time] z@ -> x
See that "z" is a symlink, and NOT a hardlink as requested by the last
Imagine what might happen if "y" were a relative symlink:
$ mkdir dir1 dir2 dir2/dir3
$ echo "hello world" >dir1/x
$ ln -s ../dir1/x dir2/y
$ cat dir2/y
$ ln dir2/y dir2/dir3/z # or "link dir2/y dir2/dir3/z"
$ ls -l dir2/dir3/z
lrwxr-xr-x 2 user group [time] dir2/dir3/z@ -> ../dir1/x
$ cat dir2/dir3/z
cat: dir2/dir3/z: No such file or directory
I don't know. I don't even know what changed this.
However, it should be noted that a hardlink to a symlink, particularly if
the symlink is a relative path, is unlikely to be useful *at all*. I
therefore classified this as a sw-bug, not a change-request, because we
now diverge in a mostly useless way from other *ix's.
Solaris's manpage for ln(1) itself reads thus:
When creating a hard link, and the source file is itself a
symbolic link, then the target will be a hard link to the
file referenced by the symbolic link, not to the symbolic
link object itself (source_file).
If our new, divergent behavior is to be kept, it should only be enabled
when a flag like "-h" is specified, and a standard "ln" or "ln -f" to a
symlink should simply fail rather than creating useless hardlinks to
Also, if this behavior is to be kept, it needs to be documented clearly in
the ln(1), link(8), and link(2) manpages.