This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug: hard links to soft links do not work


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


% 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.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]