Mail Archives: cygwin/2002/08/01/17:09:58
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/
- Raw text -