Re: cd builtin fails to resolve paths PATH_MAX in length

[Chet Ramey]

> From: karen@apple.com
> To: bug-bash@gnu.org
> Subject: cd builtin fails to resolve paths PATH_MAX in length
> 
> Machine Type: powerpc-apple-darwin8.0
> 
> Bash Version: 2.05b
> Patch Level: 0
> Release Status: release
> 
> Description:
> We have a large number of UNIX conformance tests failing. Specifically
> they fail when the cd builtin command is given a directory whose
> pathname length is (PATH_MAX - 1).
> 
> The failures only occur when invoking bash as /bin/sh.

I took a look at the test included in the report (and the separate one you
sent), and have concluded that the test is flawed.  I see what it's trying
to test, but what it's trying to test is not part of the SUS.

> The PATH_MAX limit includes the trailing null byte.  So, the conformance
> test successfully creates multiple directories such that the relative  
> path
> to the final directory is 1023 chars long, leaving room for that null  
> byte.
> Then the test tries to 'cd' to that long path and fails, even though
> the directory path exists.  The long, 1023 char, path passed to cd
> is not absolute.  It looks like the cd builtin translates the directory  
> from a relative
> path to an absoulte path which can force the resolved path to exceed  
> PATH_MAX.

This is as the SUS specifies.  If you look at

http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html

you see that the path `cd' is supposed to operate on is the (relative)
path supplied as an argument, prefixed by $PWD and `/' (step 6).  cd
explicitly works with full pathnames.

> builtins/cd.def  calls sh_canonpath() with an absolute pathname.
> In  sh_canonpath() a stat() fails because this new, absolute path  
> exceeds PATH_MAX.

As it should:  the SUS requires that the pathname be canonicalized, and
stat() is required so a pathname like /tmp/notthere/.. doesn't resolve
to /tmp, as a strictly textual treatment would do.

Whether or not the stat() fails, the SUS requires that `cd' fail,
because step 9 states that cd ``shall then perform actions equivalent
to the chdir() function called with *curpath* as the path argument,''
and chdir() must fail if handed a path longer than PATH_MAX:

http://www.opengroup.org/onlinepubs/009695399/functions/chdir.html

> The standard states:
> When 'directory' is a pathname which is a string of no more than
> PATH_MAX bytes then 'directory' can be resolved.

Where?  Not in the description of `cd' or `chdir()'.

Now, when bash is not running in `posix mode', it tries the chdir() again
using what the user typed, and attempts to use getcwd() to re-canonicalize
$PWD.  It's the call to getcwd() that fails.  I'll change things so that
PWD is set correctly, and `cd' returns success, even if there's an error
message from getcwd().

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
                                                Live...Laugh...Love
Chet Ramey, ITS, CWRU    chet@po.cwru.edu    http://tiswww.tis.cwru.edu/~chet/