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 needed. Thanks...
On Mon, Dec 5, 2011 at 11:17 AM, Russell Davis <[email protected]> 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. > > > Thanks, > Russell
