Mail Archives: cygwin/2002/05/03/02:48:20
>>-----Original Message-----
>>From: Larry Hall (RFK Partners, Inc) [mailto:lhall AT rfk DOT com]
>>Sent: Thursday, May 02, 2002 5:14 PM
>>To: Mellman Thomas; cygwin AT cygwin DOT com
>>Subject: RE: using Windows links
>>
>>
>>At 10:53 AM 5/2/2002, Mellman Thomas wrote:
>>> >>> >>Just because it isn't recognized as a Cygwin symbolic link
>>> >>> >>doesn't mean it
>>> >>> >>doesn't exist as a file as far as Cygwin is concerned.
>>> >>>
>>> >>>
>>> >>>
>>> >>>The thing is, the Windows-created Shortcut is called
>>> >>Desktop.lnk and I'm trying to create simply Desktop. There
>>> >>is NO file called Desktop. But ln(1) fails, telling me that
>>> >>Desktop exists.
>>> >>
>>> >>
>>> >>Cygwin symlinks, by default, create windows shortcuts.
>>> >>Windows shortcuts
>>> >>append ".lnk" onto the name of the file given as the
>>> >>shortcut. So you may
>>> >>think you're asking Cygwin to create "Desktop" but you're
>>> >>actually asking
>>> >>it to create "Desktop.lnk".
>>>
>>>
>>>Hmmm. Consider this:
>>>
>>>$ ln -s /h h
>>>$ lf
>>>Desktop@ h@
>>>$ ll h
>>>lrwxrwxrwx 1 Administ Kein 85 May 2 14:46 h -> /h
>>>$
>>>
>>>There's no h.lnk here.
>>>Is this just a question of having the right frame-of-mind?
>>
>>
>>".lnk" is hidden by Cygwin because it wants to treat shortcuts as
>>symlinks (unless 'nowinsymlinks' is set in the CYGWIN environment
>>variable). Look at the directory listing in a DOS box. The .lnk is
>>there.
Oh. I thought hiding magical things was what MS did. :)
(of course, you could always point out that cygwin magically
hides MS, thank goodness!)
>>> >>>Thus, cygwin is throwing in the towel on link/Shortcut
>>> >>compatibility, but I think it was forgotten to remove some of
>>> >>the code.
>>> >>
>>> >>
>>> >>Wrong on both accounts. The default Cygwin symbolic link
>>> >>creation mode
>>> >>makes shortcuts. These shortcuts are usable directly by
>>> >>Explorer and other
>>> >>Windows apps that understand Windows shortcuts. Shortcuts
>>> >>made by Windows
>>> >>are not grokked as Cygwin shortcuts however. There's nothing
>>> >>"wrong" here.
>>>
>>>
>>>I didn't use the word "wrong". I only said, "non-compatible".
>>>
>>
>>
>>OK, let's be literal. You made the following sweeping and
>>unsubstantiated
>>statement:
>>
>>"...cygwin is throwing in the towel on link/Shortcut compatibility..."
>>
>>I'm simply stating that this is not true, which I explained
>>above. The
>>current implementation is as compatible as possible given the
>>limitations of
>>shortcuts and the mismatch they have with POSIX paths. If
>>you want to know
>>more about the design issues there, check out the developers
>>archive. It was
>>all discussed there. Of course, no one will object if
>>someone finds a nice
>>solution that allows even more compatibility. But a review
>>of what's been
>>done and discussed already is beneficial to keep from
>>reintroducing bygone
>>ideas and threads.
I've accepted that the current approach is the most economical -
most practical approach for now. I'll buy your view that the
implementation is "as compatible as possible given ...".
I don't understand why my statement that "cygwin is throwing in the
towel on link/Shortcut compatibility" so disturbs you. I don't think
you can say the statement is not true. It IS true that cygwin is
wonderfully compatible in one direction, but (thanks to my employer)
I've still got to swim in and out of this damn MS sewage. So bi-directional
compatibility would be nice. But I'm still thankful for what I've got.
--
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 -