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.20020801135828.01f99230@pop3.cris.com>
X-Sender: rrschulz AT pop3 DOT cris DOT com
Date: Thu, 01 Aug 2002 14:11:07 -0700
To: 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: <20020801200325.GC27689@redhat.com>
References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020801123520 DOT 01f97010 AT pop3 DOT cris DOT com>
 <sa0eldimogw DOT fsf AT glip DOT premonitia DOT com>
 <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020801123520 DOT 01f97010 AT pop3 DOT cris DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Chris,

Are you suggesting that the Cygwin "kernel" (Cygwin1.dll) augment the new 
link name when the target is a symlink and the new name is missing the 
".lnk" extension?

Or are you suggesting that Cygwin detect symlinks / shortcuts by their 
content rather than the extension of their file names? Is there a reliably 
detectable signature to a ".lnk" file? It seems perhaps there is:

% file 3
3: ms-Windows shortcut

Contrast:

% file 2
2: symbolic link to 1

(These are the same "2" (really "2.lnk") and "3" files created by Sam's 
example.)


If you're suggesting the first approach, then will renaming a shortcut 
(anything ending in ".lnk") to omit or alter the extension elicit a failure?

It seems that only second putative solution would prevent one from seeing 
symlink cruft when accessing a misnamed symlink / shortcut. Won't you then 
feel pressure to add another option to "mount" to inhibit those 
content-based checks for the sake of speed (as you did for executables)?

I'm still not sure that "ln" isn't the proper locus for a fix to the 
problem Sam reported. (Nor am I going to do the work or suffer whatever 
consequences would ensure, so you can assign a suitable weight to that 
opinion, of course.)

Randall Schulz
Mountain View, CA USA


At 13:03 2002-08-01, Christopher Faylor wrote:
>On Thu, Aug 01, 2002 at 12:42:45PM -0700, Randall R Schulz wrote:
> >% 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.
>
>I don't think this is a 'ln' problem.  It's a cygwin problem.  If cygwin
>is doing the wrong thing then it should, as Sam said, either be made to
>work or fail, not provide binary gobbledegook.
>
>If this was to be made to work correctly, it would be pretty low level
>in cygwin in the path_conv and symlink_check methods.
>
>It would be much easier to fail in this scenario rather than make it
>work correctly, I think.
>
>cgf


--
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/