Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-Id: <5.1.0.14.2.20020801123520.01f97010@pop3.cris.com>
X-Sender: rrschulz AT pop3 DOT cris DOT com
Date: Thu, 01 Aug 2002 12:42:45 -0700
To: sds AT gnu DOT org, cygwin AT cygwin DOT com
From: Randall R Schulz <rrschulz AT cris DOT com>
Subject: Re: bug: hard links to soft links do not work
In-Reply-To: <sa0eldimogw.fsf@glip.premonitia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sam,

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 
symbolic link.

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.

Randal Schulz
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.
>
>--
>Sam Steingold


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/