This is the mail archive of the
mailing list for the Cygwin project.
Re: bug: hard links to soft links do not work
- From: Randall R Schulz <rrschulz at cris dot com>
- To: sds at gnu dot org, cygwin at cygwin dot com
- Date: Thu, 01 Aug 2002 12:42:45 -0700
- Subject: Re: bug: hard links to soft links do not work
The hard link to the symlink is made somewhat "blindly" in that the ".lnk"
suffix that indicates that the link target is itself a symlink is not
automatically added to the newly created hard link. Since the
interpretation of a file's contents as a symbolic link is not based on any
content signature (such as, say, a magic number) but rather only by the
extension, a hard link without the ".lnk" (or, equivalently, a shortcut
file renamed to omit the ".lnk" extension) will not be interpreted as a
Thus the binary junk you saw was the shortcut / symlink contents themselves.
At the end of the series of commands you gave (using an NTFS file system,
of course), this is the result (note the "inode" numbers in the left column):
% ll -i foo 1 2 3
6537940 -rw-rw-r-- 2 RSchulz None 4 Aug 1 12:34 1
10863326 lrwxrwxrwx 2 RSchulz None 82 Aug 1 12:34 2 -> 1
10863326 -r-xr-xr-x 2 RSchulz None 82 Aug 1 12:34 3*
6537940 -rw-rw-r-- 2 RSchulz None 4 Aug 1 12:34 foo
My hunch is that a patch gratefully accepted for this situation would be an
addition to the "ln" command that detected when the target was a Windows
shortcut-based Cygwin symlink and in that case supplied the ".lnk"
extension if it was not already present in the specified new link name.
Mountain View, CA USA
At 11:19 2002-08-01, Sam Steingold wrote:
cygwin does not handle hard and soft links together:
$ echo "foo" > foo
$ ln foo 1
$ cat 1
foo ; GOOD!
$ ln -s 1 2
$ cat 2
foo ; GOOD!
$ ln 2 3
$ cat 3
<some binary data instead of "foo">
I.e., hard links to soft links do not work.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html