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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org