>Number:         17411
>Category:       kern
>Synopsis:       link(2) changed behavior majorly wrt symlinks in 1.5
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 27 08:06:02 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Todd Vierling
>Release:        NetBSD 1.5 (or later, including 1.6)
>Organization:
	duh.org: Pointing out the obvious since 1994.

>Environment:
Irrelevant

>Description:

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
Linux 7.something.

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.

>How-To-Repeat:

$ 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
"ln" command.

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
hello world
$ 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

OOPS!

>Fix:

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
symlinks.

Also, if this behavior is to be kept, it needs to be documented clearly in
the ln(1), link(8), and link(2) manpages.
>Release-Note:
>Audit-Trail:
>Unformatted: