Re: canonicalize_file_name should support win32 shortcuts

[Bastien ROUCARIES]

On Tue, Aug 23, 2011 at 7:47 PM, Eric Blake  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
>
>

Re: canonicalize_file_name should support win32 shortcuts

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 24.08.2011 00:17, Bruno Haible wrote:
> Hi Vladimir,
>
>>> hash.c in order to properly detect ELOOP, which must be done as part
>>> of an unlimited-depth link following algorithm.  (If we didn't have
>>> the GNU mantra of no arbitrary limits, then we could declare ELOOP at
>>> SYMLOOP_MAX instead.)
>>>
>> Brent's algorithm is universal, sets no arbitrary limit and requires no
>> hash and is implemented in few lines at a slight cost of going through
>> the cycle potentially up to 2 (or was it 3?) times.
>> http://en.wikipedia.org/wiki/Cycle_detection#Brent.27s_algorithm
> Interesting idea.
>
> But in file system related code like here, we consider a system call to be 
> very
> expensive (as it implies a context switch to the kernel and back). Whereas
> adding one entry to a hash table is rather quick on average. Therefore we
> try to minimize the number of system calls, even if it causes an increase in
> temporary memory use.
>
There is increase in number of calls only in the case of symlink loop
which isn't normal operation condition. Wehereas code simplicity and
memory usage benefits occur in normal conditions.
But your argumentation makes sense as well. In such cases it's mostly
maintainer's personal preference which matters.
> Bruno
>
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko




signature.asc
Description: OpenPGP digital signature

Re: canonicalize_file_name should support win32 shortcuts

[Bruno Haible]

Hi Vladimir,

> > hash.c in order to properly detect ELOOP, which must be done as part
> > of an unlimited-depth link following algorithm.  (If we didn't have
> > the GNU mantra of no arbitrary limits, then we could declare ELOOP at
> > SYMLOOP_MAX instead.)
> >
> Brent's algorithm is universal, sets no arbitrary limit and requires no
> hash and is implemented in few lines at a slight cost of going through
> the cycle potentially up to 2 (or was it 3?) times.
> http://en.wikipedia.org/wiki/Cycle_detection#Brent.27s_algorithm

Interesting idea.

But in file system related code like here, we consider a system call to be very
expensive (as it implies a context switch to the kernel and back). Whereas
adding one entry to a hash table is rather quick on average. Therefore we
try to minimize the number of system calls, even if it causes an increase in
temporary memory use.

Bruno

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

> * Eric Blake  [2011-08-23 11:47:57 -0600]:
>
> On 08/23/2011 11:31 AM, Sam Steingold wrote:
>>
>>> 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.

http://article.gmane.org/gmane.comp.lib.gnulib.bugs:26452

Indeed, much better:

$ wc `hg st -u | cut -c2-`
  378  1324 10439 src/gllib/canonicalize-lgpl.c
   53   261  2011 src/gllib/dosname.h
   91   490  3191 src/gllib/lstat.c
   48   227  1525 src/gllib/pathmax.h
   74   347  2355 src/gllib/readlink.c
  105   458  3425 src/gllib/stat.c
  658  2489 18324 src/gllib/sys_stat.in.h
  249  1093  9223 src/gllib/time.in.h
   94   274  2986 src/glm4/canonicalize.m4
   38   212  1621 src/glm4/double-slash-root.m4
   69   274  2652 src/glm4/lstat.m4
   1355   441 src/glm4/pathmax.m4
   62   210  2218 src/glm4/readlink.m4
   66   250  2436 src/glm4/stat.m4
   82   259  3278 src/glm4/sys_stat_h.m4
  109   305  4247 src/glm4/time_h.m4
 2189  8528 70372 total

Still I get 2000+ lines to replace 200- lines I have.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://www.memritv.org http://mideasttruth.com
http://openvotingconsortium.org http://ffii.org http://dhimmi.com
Why do you never call me back after I scream that I will never talk to you 
again?!

Re: canonicalize_file_name should support win32 shortcuts

[Eric Blake]

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.



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

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

> * Eric Blake  [2011-08-23 10:35:52 -0600]:
>
> On 08/23/2011 10:28 AM, Sam Steingold wrote:
>>> Does Hurd have SYMLOOP_MAX?  If so, then yes, that would be a reasonable
>>> change.  If not, then how do you propose implementing canonicalize on
>>> Hurd, without imposing a limit not already present by the system?
>>
>> Are you saying that you want to replace realpath on a GNU system?
>
> Have you read the canonicalize module?  It does _not_ provide
> canonicalize() (which is a thin wrapper around realpath(), but which is
> inherently limited in what it can do), but a broader API
> canonicalize_filename_mode(const char *name, canonicalize_mode_t mode),
> where the extra argument mode allows you to canonicalize whether a file
> name can be created (all its parents exist), or even to canonicalize
> what exists but leave the suffix intact (multiple parents still need
> creation).  That is, there is no libc functions that do what we want in
> a single blow, not even realpath(), so we have to do a lot of work to
> get the extended functionality, all of which is useful in coreutils'
> realpath(1).

I see. So, the canonicalize module is an "extension", not a
"portability" module, i.e., it offers new non-posix functionality
instead of making sure that the weird platforms conform to posix.
Thanks for explaining.

> ... enhanced with gpl code to parse symlinks left by cygwin even when
> running as a non-cygwin native windows program.  But why?  Windows
> doesn't have symlinks, and cygwin is free to change its symlink
> emulation in the future.  Does it really make sense to teach
> non-cygwin programs about cygwin file formats?

First of all, newer windows do have symlinks.
Second, canonicalize is already an extension module, so why not extend
it to work well with a popular extension of a popular platform? :-)

> 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).

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://thereligionofpeace.com http://camera.org
http://dhimmi.com http://memri.org http://truepeace.org
Be sure brain is in gear before engaging mouth.

Re: canonicalize_file_name should support win32 shortcuts

[Eric Blake]

On 08/23/2011 10:28 AM, Sam Steingold wrote:

Does Hurd have SYMLOOP_MAX?  If so, then yes, that would be a reasonable
change.  If not, then how do you propose implementing canonicalize on
Hurd, without imposing a limit not already present by the system?


Are you saying that you want to replace realpath on a GNU system?


Have you read the canonicalize module?  It does _not_ provide 
canonicalize() (which is a thin wrapper around realpath(), but which is 
inherently limited in what it can do), but a broader API 
canonicalize_filename_mode(const char *name, canonicalize_mode_t mode), 
where the extra argument mode allows you to canonicalize whether a file 
name can be created (all its parents exist), or even to canonicalize 
what exists but leave the suffix intact (multiple parents still need 
creation).  That is, there is no libc functions that do what we want in 
a single blow, not even realpath(), so we have to do a lot of work to 
get the extended functionality, all of which is useful in coreutils' 
realpath(1).


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).


It sounds like what you want is a version of canonicalize() that only 
has the raw realpath() functionality provided by the canonicalize-lgpl 
module, but enhanced with gpl code to parse symlinks left by cygwin even 
when running as a non-cygwin native windows program.  But why?  Windows 
doesn't have symlinks, and cygwin is free to change its symlink 
emulation in the future.  Does it really make sense to teach non-cygwin 
programs about cygwin file formats?


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

> * Eric Blake  [2011-08-23 08:46:00 -0600]:
>
> On 08/23/2011 08:41 AM, Sam Steingold wrote:
>>> * Eric Blake  [2011-08-23 08:03:02 -0600]:
>>>
>>> On 08/23/2011 07:56 AM, Sam Steingold wrote:
 Let me reiterate that the size of canonicalize is plain absurd:
 .
 150+ files to implement a single function which takes ~160 lines of C code.
 These files includes things like hash.c and fchownat.c (why?!)
>>>
>>> hash.c in order to properly detect ELOOP, which must be done as part of
>>> an unlimited-depth link following algorithm.  (If we didn't have the GNU
>>> mantra of no arbitrary limits, then we could declare ELOOP at
>>> SYMLOOP_MAX instead.)
>>
>> ELOOP at SYMLOOP_MAX sounds good to me.
>
> Does Hurd have SYMLOOP_MAX?  If so, then yes, that would be a reasonable
> change.  If not, then how do you propose implementing canonicalize on
> Hurd, without imposing a limit not already present by the system?

Are you saying that you want to replace realpath on a GNU system?
Are you trying to be holier than the pope?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://camera.org http://jihadwatch.org http://memri.org
http://palestinefacts.org http://thereligionofpeace.com http://iris.org.il
main(a){a="main(a){a=%c%s%c;printf(a,34,a,34);}";printf(a,34,a,34);}

Re: canonicalize_file_name should support win32 shortcuts

[Vladimir 'φ-coder/phcoder' Serbinenko]

> hash.c in order to properly detect ELOOP, which must be done as part
> of an unlimited-depth link following algorithm.  (If we didn't have
> the GNU mantra of no arbitrary limits, then we could declare ELOOP at
> SYMLOOP_MAX instead.)
>
Brent's algorithm is universal, sets no arbitrary limit and requires no
hash and is implemented in few lines at a slight cost of going through
the cycle potentially up to 2 (or was it 3?) times.
http://en.wikipedia.org/wiki/Cycle_detection#Brent.27s_algorithm
it's not more difficult than setting SYMLOOP_MAX.
I'm ok to implement it in gnulib, just not until the end of my exams

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko




signature.asc
Description: OpenPGP digital signature

Re: canonicalize_file_name should support win32 shortcuts

[Eric Blake]

On 08/23/2011 08:41 AM, Sam Steingold wrote:

* Eric Blake  [2011-08-23 08:03:02 -0600]:

On 08/23/2011 07:56 AM, Sam Steingold wrote:

Let me reiterate that the size of canonicalize is plain absurd:
.
150+ files to implement a single function which takes ~160 lines of C code.
These files includes things like hash.c and fchownat.c (why?!)


hash.c in order to properly detect ELOOP, which must be done as part of
an unlimited-depth link following algorithm.  (If we didn't have the GNU
mantra of no arbitrary limits, then we could declare ELOOP at
SYMLOOP_MAX instead.)


ELOOP at SYMLOOP_MAX sounds good to me.


Does Hurd have SYMLOOP_MAX?  If so, then yes, that would be a reasonable 
change.  If not, then how do you propose implementing canonicalize on 
Hurd, without imposing a limit not already present by the system?


Most other systems have SYMLOOP_MAX, at which point, canonicalize 
succeeding where the native system would fail due to ELOOP does indeed 
sound fishy (what good is it to know what a symlink ultimately resolved 
to if the system can't do the same resolution?)


But someone has to write the patches, and it's not my highest priority 
at the moment.



Please note that gnulib's mandate (as far as _I_ understand it) is
to turn a random system into a POSIX system, not a GNU system.
Please provide a separate module when you want to follow the GNU mantra,
like you do with fnmatch.

Thanks!


fchownat.c because the openat module has too many functions.


I would say that all the "f*" (i.e., using FILE*) files are an overkill.


fchownat.c does NOT use FILE*.  It operates on fd, the same as openat. 
That is, fchownat() is roughly a superset of both fchown() (fds) and 
chown() (names).


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

> * Eric Blake  [2011-08-23 08:03:02 -0600]:
>
> On 08/23/2011 07:56 AM, Sam Steingold wrote:
>> Let me reiterate that the size of canonicalize is plain absurd:
>> .
>> 150+ files to implement a single function which takes ~160 lines of C code.
>> These files includes things like hash.c and fchownat.c (why?!)
>
> hash.c in order to properly detect ELOOP, which must be done as part of
> an unlimited-depth link following algorithm.  (If we didn't have the GNU
> mantra of no arbitrary limits, then we could declare ELOOP at
> SYMLOOP_MAX instead.)

ELOOP at SYMLOOP_MAX sounds good to me.
Please note that gnulib's mandate (as far as _I_ understand it) is
to turn a random system into a POSIX system, not a GNU system.
Please provide a separate module when you want to follow the GNU mantra,
like you do with fnmatch.

Thanks!

> fchownat.c because the openat module has too many functions.

I would say that all the "f*" (i.e., using FILE*) files are an overkill.

> Anyone willing to split openat into multiple modules, one per
> function, more like other gnulib modules?

Please!

>> as well as __BOTH__ malloc.c and xmalloc.c.
>
> Depending on xmalloc is probably overkill - having a version of
> canonicalize that returns NULL with ENOMEM instead of abort()ing would
> indeed be nicer.  Anyone willing to contribute patches to break that
> part of the dependency chain()

Please!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://pmw.org.il http://iris.org.il http://ffii.org http://honestreporting.com
http://www.PetitionOnline.com/tap12009/ http://openvotingconsortium.org
(let((a'(list'let(list(list'a(list'quote a)))a)))`(let((a(quote ,a))),a))

Re: canonicalize_file_name should support win32 shortcuts

[Eric Blake]

On 08/23/2011 07:56 AM, Sam Steingold wrote:

Let me reiterate that the size of canonicalize is plain absurd:
.
150+ files to implement a single function which takes ~160 lines of C code.
These files includes things like hash.c and fchownat.c (why?!)


hash.c in order to properly detect ELOOP, which must be done as part of 
an unlimited-depth link following algorithm.  (If we didn't have the GNU 
mantra of no arbitrary limits, then we could declare ELOOP at 
SYMLOOP_MAX instead.)


fchownat.c because the openat module has too many functions.  Anyone 
willing to split openat into multiple modules, one per function, more 
like other gnulib modules?



as well as __BOTH__ malloc.c and xmalloc.c.


Depending on xmalloc is probably overkill - having a version of 
canonicalize that returns NULL with ENOMEM instead of abort()ing would 
indeed be nicer.  Anyone willing to contribute patches to break that 
part of the dependency chain()


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

> * Bruno Haible  [2011-08-14 14:51:55 +0200]:
>
> Sam, if 'canonicalize' gets this support, would you be willing to use
> 'canonicalize'

Let me reiterate that the size of canonicalize is plain absurd:
.
150+ files to implement a single function which takes ~160 lines of C code.
These files includes things like hash.c and fchownat.c (why?!)
as well as __BOTH__ malloc.c and xmalloc.c.

> instead of 'canonicalize-lgpl' in clisp?

For the record, I am _not_ using `canonicalize-lgpl'.

I have been reluctant to pull this code bloat into clisp so far,
but if it does provide a clear advantage of handling cygwin symlinks on
pure win32 builds, I will reconsider.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://openvotingconsortium.org http://www.PetitionOnline.com/tap12009/
http://www.memritv.org http://memri.org http://camera.org
Single tasking: Just Say No.

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

On Sun, Aug 14, 2011 at 8:51 AM, Bruno Haible  wrote:
>
> Sam, if 'canonicalize' gets this support, would you be willing to use
> 'canonicalize' instead of 'canonicalize-lgpl' in clisp?

yes.

-- 
Sam Steingold 

Re: canonicalize_file_name should support win32 shortcuts

[Bruno Haible]

Sam Steingold wrote:
> > The feature request is a bit odd, because it mixes the notion of
> > "native Windows" and Cygwin. Cygwin is a platform that runs inside Windows.
> > When you build mingw programs, and redistribute them, they are meant to
> > run in a native Windows environment, in which no Cygwin symlinks exist.
> 
> I have not seen a windows machine without cygwin for longer than it
> took me to install it.
> CLISP understands those "/cygdrive/c/autoexec.bat" pathnames just
> fine, and understanding symlinks is just another step forward.
> 
> > Other non-Cygwin applications don't understand Cygwin symlinks either.
> 
> Emacs understands the cygdrive pathnames and I am sure it will
> appreciate an opportunity to understand symlinks as well.

Jim, are you in favour or against adding support for Cygwin symlinks to
the 'canonicalize' module? It may also require us to split 'lstat' into
two modules: 'lstat', under GPL, with this support, and 'lstat-lgpl',
without it.

Sam, if 'canonicalize' gets this support, would you be willing to use
'canonicalize' instead of 'canonicalize-lgpl' in clisp?

Bruno
-- 
In memoriam Maximilian Kolbe 

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

Hi Bruno,

On Sat, Aug 13, 2011 at 1:52 PM, Bruno Haible  wrote:
>
> The feature request is a bit odd, because it mixes the notion of
> "native Windows" and Cygwin. Cygwin is a platform that runs inside Windows.
> When you build mingw programs, and redistribute them, they are meant to
> run in a native Windows environment, in which no Cygwin symlinks exist.

I have not seen a windows machine without cygwin for longer than it
took me to install it.
CLISP understands those "/cygdrive/c/autoexec.bat" pathnames just
fine, and understanding symlinks is just another step forward.

> Other non-Cygwin applications don't understand Cygwin symlinks either.

Emacs understands the cygdrive pathnames and I am sure it will
appreciate an opportunity to understand symlinks as well.

-- 
Sam Steingold 

Re: canonicalize_file_name should support win32 shortcuts

[Bruno Haible]

Hi Sam,

Sam Steingold wrote in
 and
:
> > it appears that neither canonicalize nor canonicalize-lgpl support win32
> > shortcuts (either used directly or as used by cygwin).
> > it would be nice if they did - then we would be able to use
> > canonicalize-lgpl in clisp.
> >
> > now clisp uses file w32shell.c:
> > http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/raw-file/363f5b952505/src/w32shell.c
> > which works like a charm for us.
> > it would be wonderful if we could shift the burden of maintaining it to you.
> 
> Alas, clisp only supports the "*.lnk" style cygwin symlinks, not the now
> default "cookie" style.
> You will need to extract parts of winsup/cygwin/path.cc to support both 
> styles.
> My feature request still stands.

The feature request is a bit odd, because it mixes the notion of
"native Windows" and Cygwin. Cygwin is a platform that runs inside Windows.
When you build mingw programs, and redistribute them, they are meant to
run in a native Windows environment, in which no Cygwin symlinks exist.
Other non-Cygwin applications don't understand Cygwin symlinks either.

Also, we have a copyright problem: while it would technically be possible to
copy the code from winsup/cygwin/path.cc to gnulib, and update the copyright
holder to "Red Hat, Inc. and Free Software Foundation, Inc.", Red Hat's
license allows redistribution under GPL, but not under LGPL. So we could add
it to module 'canonicalize', but not to module 'canonicalize-lgpl'.
(By the way, you need to add Red Hat to the list of copyright holders of
clisp/src/w32shell.c, because of the copied code.)

Bruno
-- 
In memoriam Paul Richter 

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

> * Sam Steingold  [2011-05-17 14:11:54 -0400]:
>
> it appears that neither canonicalize nor canonicalize-lgpl support win32
> shortcuts (either used directly or as used by cygwin).
> it would be nice if they did - then we would be able to use
> canonicalize-lgpl in clisp.
>
> now clisp uses file w32shell.c:
> http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/raw-file/363f5b952505/src/w32shell.c
> which works like a charm for us.
> it would be wonderful if we could shift the burden of maintaining it to you.

Alas, clisp only supports the "*.lnk" style cygwin symlinks, not the now
default "cookie" style.
You will need to extract parts of winsup/cygwin/path.cc to support both styles.
My feature request still stands.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://ffii.org http://www.memritv.org http://pmw.org.il http://dhimmi.com
http://openvotingconsortium.org http://thereligionofpeace.com
Takeoffs are optional.  Landings are mandatory.

canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

it appears that neither canonicalize nor canonicalize-lgpl support win32
shortcuts (either used directly or as used by cygwin).
it would be nice if they did - then we would be able to use
canonicalize-lgpl in clisp.

now clisp uses file w32shell.c:
http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/raw-file/363f5b952505/src/w32shell.c
which works like a charm for us.
it would be wonderful if we could shift the burden of maintaining it to you.

thanks!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://mideasttruth.com http://honestreporting.com http://palestinefacts.org
http://jihadwatch.org http://memri.org http://iris.org.il
Lisp suffers from being twenty or thirty years ahead of time.