This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[RFD]: Should Cygwin use the old symlink style as default again?


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@cygwin.com
Red Hat, Inc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]