bug: hard links to soft links do not work

[Randall R Schulz]

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/