Add support for creating native windows symlinks
Sun Dec 18 20:16:00 GMT 2011
Can someone respond to this? If there's a problem with my suggested
approach I'd like to know what it is. Let me know if clarification is
On Mon, Dec 5, 2011 at 11:17 AM, Russell Davis <firstname.lastname@example.org> wrote:
> > See also http://sourceware.org/ml/cygwin/2009-10/msg00756.html
> Quoting from that link:
> - Due to the way they are used in the Win32 API, there's no way to
> use them with POSIX paths *and* Win32 paths for interoperability.
> So why bother?
> Yeah, this is rather unfortunate. I agree, since we can't store both
> the Win32 AND the POSIX path, it's not possible for native symlinks to
> function correctly both inside and outside of cygwin for all possible
> cases. But the point I've been making is this -- if we can make them
> work within cygwin for 100% of cases, and outside of cygwin for 90% of
> cases, what's the problem? It's still better than the existing cygwin
> symlinks which work 100% within cygwin and 0% outside of cygwin.
> If the "works within cygwin for 100% of cases" is in question, let's
> discuss that. (Any path that might be problematic as a Win32 path can
> just be stored as a POSIX path, and would fall into the bucket of
> "works inside cygwin but not outside").
> > There's also a problem with your patch.
> Thanks, I figured it would need some clean up and polish. I wanted to
> get it out there as a starting point.
More information about the Cygwin-patches