This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: [RFD]: Should Cygwin use the old symlink style as default again?
- To: cygdev <cygwin-developers at cygwin dot com>
- Subject: Re: [RFD]: Should Cygwin use the old symlink style as default again?
- From: Earnie Boyd <earnie_boyd at yahoo dot com>
- Date: Wed, 30 May 2001 09:13:49 -0400
- References: <20010530093030.C23313@cygbert.vinschen.de>
- Reply-To: Cygwin Developers <cygwin-developers at cygwin dot com>
Corinna Vinschen wrote:
>
> Hi,
>
> after several weeks of the community testing the new .lnk symlink style,
> it turns out that this constitutes some new problems I wasn't aware when
> creating it.
>
> Keep in mind that the advantage of using shortcuts as symlinks are not
> on Cygwin side but on native Windows side. While Cygwin always had
> symlinks and could use them (mostly) without problems, we had several
> times request of the type "why are Cygwin symlinks not usable in
> Explorer?" etc. The .lnk method just adds the ability of native Windows
> to utilize Cygwin symlinks for it's own dubious purposes...
>
> Cygwin can read native Windows shortcuts as well but it can only read
> and use the target information in the shortcut, nothing else.
>
> What are the problems now?
>
> The most important point is that Windows shortcuts contain more
> information than just a path to a target. They may contain an icon
> information, a description, a shortcut key and last but not least command
> line arguments for a target application.
>
> If these shortcuts are treated as symlinks, these information is lost
> when creating for example a tar archive containing these files. Since
> they are treated as symlinks, they are recreated as Cygwin symlinks when
> unpacking the tar archive... so all information except for the bare
> target is lost.
>
> As a result, it's impossible to create tar backups of, say, your profile
> directory.
>
> For that reason I have patched the shortcut code in the current CVS
> version so that only Cygwin (and U/WIN) shortcuts are treated as
> symlinks, while native shortcuts are treated as plain files again.
>
> The next disadvantage is that the evaluation of .lnk symlinks is more
> time consuming than the evaluation of old style symlinks.
>
> Since it's impossible to keep .lnk symlinks as a general solution but
> only for Cygwin symlinks, it seems a bit senseless to keep this method
> for the future except for the very first point, "native Windows can use
> Cygwin symlinks as well".
>
What about the using the system bit hack again? If the system bit is
set on the .lnk file then consider it a Cygwin symlink. I don't think
you can set the system bit on a shortcut via the Win32 GUI, at least I
can't in my session using NT4, so you don't need to be concerned for the
extra information if the system bit is set.
> We don't want to drop the shortcut method completely for backward
> compatibility reasons but the question is:
>
> Shall we return to the old symlink style as default?
>
Perhaps. Only if nothing else can be established to be effective at
identifying the Cygwin symlinks.
--
Earnie.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com