Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Wed, 30 May 2001 09:30:30 +0200
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygdev <cygwin-developers AT cygwin DOT com>
Subject: [RFD]: Should Cygwin use the old symlink style as default again?
Message-ID: <20010530093030.C23313@cygbert.vinschen.de>
Reply-To: cygdev <cygwin-developers AT cygwin DOT com>
Mail-Followup-To: cygdev <cygwin-developers AT cygwin DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i

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".

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?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.