Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Message-ID: <3B14F20D.D799DF03@yahoo.com>
Date: Wed, 30 May 2001 09:13:49 -0400
From: Earnie Boyd <earnie_boyd AT yahoo DOT com>
Reply-To: Cygwin Developers <cygwin-developers AT cygwin DOT com>
MIME-Version: 1.0
To: cygdev <cygwin-developers AT cygwin DOT com>
Subject: Re: [RFD]: Should Cygwin use the old symlink style as default again?
References: <20010530093030 DOT C23313 AT cygbert DOT vinschen DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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