On Tue, Aug 23, 2011 at 7:47 PM, Eric Blake <ebl...@redhat.com> wrote: > On 08/23/2011 11:31 AM, Sam Steingold wrote: >> >> First of all, newer windows do have symlinks. > > Does mingw support them natively? If not, then we should get that fixed in > mingw; perhaps by starting with an lstat() that actually works on windows > symlinks.
It is such a mess see for instance http://cygwin.com/ml/cygwin/2009-08/msg00794.html they are six kind of symlink in windows >> Second, canonicalize is already an extension module, so why not extend >> it to work well with a popular extension of a popular platform? :-) > > I'm not so concerned about supporting cygwin symlinks outside of cygwin as I > am in supporting native windows symlinks from native windows programs. This > is where an lgpl implementation of dealing with native windows symlinks > would be useful. > >> >>> Maybe we should rename the canonicalize module to instead be >>> canonicalize_filename_mode, since it does _not_ provide canonicalize() >>> (well, canonicalize_filename_mode(file, CAN_EXISTING) is identical to >>> canonicalize(), but the other modes are what introduce the baggage). >> >> yes, I think there should be a very minimalist realpath module whose job >> is to provide the posix realpath with minimum dependencies (well, >> minimum dependencies is my constant mantra, applicable to extension >> modules just as much as to portability ones). > > canonicalize-lgpl _is_ the minimalize realpath()/canonicalize() module. > It's just that we need to have a mingw setup that supports native windows > symlinks using lgpl code, before canonicalize-lgpl can take advantage of it. > > -- > Eric Blake ebl...@redhat.com +1-801-349-2682 > Libvirt virtualization library http://libvirt.org > >
