bug-gnulib
[Top][All Lists]
Advanced

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

Re: [Bug-gnulib] gnulib imports from coreutils for canon-host, human, xg


From: Jim Meyering
Subject: Re: [Bug-gnulib] gnulib imports from coreutils for canon-host, human, xgetcwd
Date: Fri, 19 Nov 2004 11:29:13 +0100

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>> If anyone pursues this, have a look at getcwd-path-max.m4.
>> It has almost all of the code required for such an autoconf test.
>
> How about if we replace the current lib/getcwd.c with a copy of
> glibc sysdeps/posix/getcwd.c, adjusted a bit to fit into gnulib

If you use that version of getcwd, then you'll have to fix more than
some memory allocation bugs to make it truly robust.  Currently it
never changes the working directory, and applies lstat and opendir to
names like ../../.., ../../../.., ../../../../F, etc.  That approach is
not only inefficient (lstat processes O(n^2) file name components) for
very deep trees, but it also imposes a limit of about PATH_MAX/3 on the
number of components in the longest current directory name it can handle.

I changed coreutils' pwd to work as long as there's enough virtual
memory to compute/store the result, but I don't think we want getcwd
do that.  If it did, then we'd have to worry about applying e.g., chdir,
lstat, etc. to such long names -- those functions can all fail with
ENAMETOOLONG.

For grins, I just exec'd coreutils' pwd from a working directory that
was 500,000 levels deep (pwd output of length 1MB).  It took only about
3 seconds (and lots of inodes) on a linux-2.6.9 tmpfs file system.

It's really too bad that there is no system interface that allows a
program to save and restore the current working directory reliably, e.g.,
regardless of dir permissions (which can make open or getcwd fail),
and file system auditing (which can make fchdir fail).

...
> That way, getcwd.c and getcwd.m4 would implement getcwd compatibly
> with glibc.   And perhaps we could remove robust_getcwd from pwd.c,
> since we could rely on glibc semantics?
...




reply via email to

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