This is the mail archive of the
mailing list for the Cygwin project.
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
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
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.)
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: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html