Re: ia64 GNU/Linux pwd-long test failure in CVS coreutils

[Bob Proulx]

Jim Meyering wrote:
> I should have created a directory whose abs. name length
> is a little *larger* than 16K, not just smaller.
> 
> Does it provoke the failed assertion if you change this line
> 
>   size_t buf_len = 16 * 1024;
> 
> to e.g., this:
> 
>   size_t buf_len = 20 * 1024;

Yes.  At 20k the mkdir succeeds, the chdir succeeds, the desired depth
is reached and then the getcwd fails.  The getcwd fails with errno
equal to 36 "File name too long" as expected.  It cleans up the
created directory structure.

  $ ls -log
  total 36
  -rwxr-xr-x  1 29101 Jun 18 11:54 getcwd-glibc-bug
  -rw-r--r--  1  1180 Jun 18 11:56 getcwd-glibc-bug.c
  $ ./getcwd-glibc-bug ; echo $?
  4
  $ ls -log
  total 36
  -rwxr-xr-x  1 29101 Jun 18 11:54 getcwd-glibc-bug*
  -rw-r--r--  1  1180 Jun 18 11:56 getcwd-glibc-bug.c

One thing that I am a little worried about by the test is the initial
mkdir call.

      if (mkdir (dir_name, S_IRWXU) < 0 || chdir (dir_name) < 0)
        {
          fail = 3; /* Unable to construct deep hierarchy.  */

That also fails if remnants of the test structure are left behind by a
previous failed run of the test or if there is not enough permission
to create a directory and other things like that.  Not sure that is
really bad but my paranoia causes me to suggest that the first mkdir
be checked individually to separate out the two different types of
failures.  And then it always tries to rmdir regardless in that case.
Check this out.

  $ mkdir confdir-14B---
  $ ./getcwd-glibc-bug ; echo $?
  3
  $ ./getcwd-glibc-bug ; echo $?
  4

The test program removes the directory that it did not create.  That
might be a self-healing feature in the simple case but it can't remove
a deep hierarchy if one was created.  I think the cleanup should
really only happen if (d > 0) meaning that we actually created the
directory ourselves.

  if (d > 0)
    rmdir (dir_name);
  while (0 < d--)

What do you think?

Bob