Discussion:
followup on native symlink support
James Gregurich
2013-10-01 15:49:23 UTC
Permalink
hi.


I've been using a recent version of cygwin with CYGWIN=winsymlinks:native setting for daily work for some weeks. I haven't experienced any problems with the feature. Its always worked as expected. I think you made a good choice to depart from my original design recommendation on converting relative paths that exceed PATH_MAX to "\??\" tagged absolute paths. We have since run into some use cases where that caused undesirable behavior. It caused symlinks that were specific to particular users on particular systems to get committed to our repository.


I wanted to write in to thank Corrina and the other cygwin maintainers involved for finally getting tired of hearing me whine and implementing the feature. :)

I still need to implement a utility to update existing cygwin symlinks to native symlinks, but that isn't a hard task…its drudgery…but not hard.


thanks,
James
Corinna Vinschen
2013-10-14 13:15:37 UTC
Permalink
Hi James,
Post by James Gregurich
hi.
I've been using a recent version of cygwin with
CYGWIN=winsymlinks:native setting for daily work for some weeks. I
haven't experienced any problems with the feature. Its always worked
as expected. I think you made a good choice to depart from my original
design recommendation on converting relative paths that exceed
PATH_MAX to "\??\" tagged absolute paths.
^^^^^^^^
I assume you mean MAX_PATH, the Windows 260 chars value, rather than
PATH_MAX, the POSIX variation which is set to 4096 on Cygwin.

This isn't quite as it is implemented, actually. In fact, Cygwin will
produce relative native symlinks, if the underlying native source and
target paths of the symlink share a common path prefix. It can do so
without taking MAX_PATH into account, because, to the best of my
knowledge, the Windows implementation of native symlinks doesn't share
this relative path length restriction with the other file API calls.

However, if the underlying native source and target paths do *not* share
a common path prefix, Cygwin has no choice but to create the symlink as
an absolute symlink. Consider a POSIX path which points to another
drive via /etc/fstab. Something like

foo -> ../baz/bar

could easily translate into

C:\foo -> D:\bar

There's no way to express this as relative path.
Post by James Gregurich
We have since run into some
use cases where that caused undesirable behavior. It caused symlinks
that were specific to particular users on particular systems to get
committed to our repository.
I wanted to write in to thank Corrina and the other cygwin maintainers
s/rrin/rinn/


Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Loading...