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
