[Top][All Lists]

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

Re: coreutils-8.13.29-43a9

From: Jim Meyering
Subject: Re: coreutils-8.13.29-43a9
Date: Sun, 09 Oct 2011 10:46:33 +0200

Bruno Haible wrote:
> On HP-UX 11.31 with cc:
> FAIL: rm/deep-2
> FAIL: rm/deep-2 (exit: 1)
> =========================
> + : perl
> + perl -e 'my $d = "x" x 200; foreach my $i (1..52)' -e ' { mkdir ($d,
> 0700) && chdir $d or die "$!" }'
> + cd ..
> + echo n
> + rm ---presume-input-tty -r x
> rm: cannot remove x/xxxxxxxxx... ...':
> File name too long
> + fail=1

That name is 1207 bytes long, which must be larger than HPUX 11.31's PATH_MAX.

remove.c's write_protected_non_symlink must be
calling euidaccess_stat with the long "full_name".
Obviously, that would fail with "File name too long".

This is a problem on HPUX because it lacks *at-function support.
One way to work around it would be to change this:

-   if (!openat_needs_fchdir ())
+   if (1)

But that would make rm use the fully emulated faccessat, which may actually
call fchdir, and which fails in the unusual event that save_cwd fails.

This is all in a very deep dark corner, so my first reaction reluctance
to compromise the implementation just to accommodate systems that lack
openat and/or /proc/self/fd support.  However, once my brain engaged,
I realized that using "imperfect" at-function emulation here would have
no impact.  What happens when we determine this file is removable?

We unlink it via unlinkat.

That unlinkat function uses the very same underlying emulation code
that faccessat does, so there is no reason to limit faccessat
use to when we have adequate openat/proc support.  Just use it all
of the time and remove the ugly hacks.

Patch coming up...

reply via email to

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