Note kernel version where Linux stopped following symbolic

links in 'oldpath'; see also http://lwn.net/Articles/294667.
POSIX.1-2008 makes it implementation-dependent whether or not
'oldpath' is dereferenced if it is a symbolic link.

man2/link.2

@@ -28,7 +28,7 @@
 .\" Modified 2004-06-23 by Michael Kerrisk <mtk.manpages@gmail.com>
 .\" Modified 2005-04-04, as per suggestion by Michael Hardt for rename.2
 .\"
-.TH LINK 2 2004-06-23 "Linux" "Linux Programmer's Manual"
+.TH LINK 2 2008-08-21 "Linux" "Linux Programmer's Manual"
 .SH NAME
 link \- make a new name for a file
 .SH SYNOPSIS
@@ -126,7 +126,7 @@ are not on the same mounted file system.
 does not work across different mount points,
 even if the same file system is mounted on both.)
 .SH "CONFORMING TO"
-SVr4, 4.3BSD, POSIX.1-2001 (except as noted above).
+SVr4, 4.3BSD, POSIX.1-2001 (but see NOTES).
 .\" SVr4 documents additional ENOLINK and
 .\" EMULTIHOP error conditions; POSIX.1 does not document ELOOP.
 .\" X/OPEN does not document EFAULT, ENOMEM or EIO.
@@ -143,7 +143,9 @@ POSIX.1-2001 says that
 should dereference
 .I oldpath
 if it is a symbolic link.
-However, Linux does not do so: if
+However, since kernel 2.0,
+.\" more precisely: since kernel 1.3.56
+Linux does not do so: if
 .I oldpath
 is a symbolic link, then
 .I newpath
@@ -158,6 +160,12 @@ Some other implementations behave in the same manner as Linux.
 .\" behaves like Linux, and contributors to a March 2005
 .\" thread in the Austin mailing list reported that some
 .\" other (System V) implementations did/do the same -- MTK, Apr 05
+
+POSIX.1-2008 changes the specification of
+.BR link (),
+making it implementation-dependent whether or not
+.I oldpath
+is dereferenced if it is a symbolic link.
 .SH BUGS
 On NFS file systems, the return code may be wrong in case the NFS server
 performs the link creation and dies before it can say so.