Well more on links:
Because cygwin does use windows shortcuts as symbolic links, it will
automaticly dereference windows links. If the link has a unix path in the
description field cygwin will use that (or at least I think it uses it, it
puts it there on its own links). Otherwise it uses the path information in
the shortcut, and converts it to a unix path.
Now a comment on relative linking and etc.
There are two sections in a shortcut that that descibe where the target file
is. One is optional (strictly both are, but such a shorcut would be
useless). It is known as shellidlist. The other is a simple windows path.
Shellidlist is always absolute. The path can be a relative path. Windows
will use the shell id list if available falling back on the path. Therefore
relative symbolic links are not relative (as far as windows cares) unless
they lack the shellidlist section. The lack of the shelidlist is also what
makes the lists uneditable in explorer.exe (as I alluded to in my previous
message.)
Now for some reason it seems that cygwin will sometimes create shortcuts
with shellidlist, and othertimes without. (This may be system dependent, OS
dependent, or perhaps a change between cygwin.dll versions.
It really does not matter though. What we have right now works, and lets
cygwin resolve shortcuts, and windows resolve cygwin's symbolic links, so
just leave it alone.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/