[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: canonicalize_file_name should support win32 shortcuts

From: Sam Steingold
Subject: Re: canonicalize_file_name should support win32 shortcuts
Date: Tue, 23 Aug 2011 13:31:29 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

> * Eric Blake <address@hidden> [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).


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]