bug-coreutils
[Top][All Lists]
Advanced

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

Re: coreutils inaccessible test fails on HP-UX with CVS build


From: Jim Meyering
Subject: Re: coreutils inaccessible test fails on HP-UX with CVS build
Date: Sat, 17 Jun 2006 09:35:42 +0200

address@hidden (Bob Proulx) wrote:

> Jim Meyering wrote:
>> On HP-UX, rm has to use a different code path for that case, since the
>> system provides neither openat-like functions, nor a /proc/self/fd-like
>> way to emulate them.
>>
>> Does this patch solve the problem?
>> ...
>> +# HP-UX 11.11 goes a different route, too.
>> +# ...: unable to record current working directory: Permission denied
>> +sed 's/: unable to record current.*/: Permission denied/'<out>o1;mv o1 out
>
> Not quite.  Almost.  But this different sed line does solve the output
> differences.
>
>   sed "s/: unable to record current.*/: cannot remove \`rel': Permission 
> denied/"<out>o1;mv o1 out
>
> However the test still failed.  Looking deeper I see this:
>
>   + test -d 
> /usr/local/build/coreutils/hppa-hpux11.11-gcc-coreutils/build/tests/rm/inaccessible.tmp/1226/abs1
>   + fail=1
>   + test -d 
> /usr/local/build/coreutils/hppa-hpux11.11-gcc-coreutils/build/tests/rm/inaccessible.tmp/1226/abs2
>   + fail=1
>
> This is the test code:
>   (cd no-access; chmod 0 . && rm -r $p/abs1 rel $p/abs2) 2> out && fail=1
>
> But the $p/abs1 and $p/abs2 dirs are not removed.  The rm fails
> earlier, bails out, and those directories remain unremoved.  Hmm...

Hi Bob,

The problem is that there is no way to record the working directory in
that pathological case (chmod 0 .), and rm would need to return to it
after traversing/removing abs1, in order to interpret the following,
relative name, "rel".  On systems with openat support, there is no need
to change directory, so everything works fine.  Without openat, rm tries
to use chdir, but that works only if save_cwd/restore_cwd also work.

Making rm use the newly rewritten fts.c might also work, because that
can revert all the way back to using full file names (no chdir) when
necessary.  But that would fail if any encountered name were longer
than PATH_MAX.  Besides, I'm not convinced it'd be an improvement.

Here's a patch to skip this test on such systems:

Index: tests/rm/inaccessible
===================================================================
RCS file: /fetish/cu/tests/rm/inaccessible,v
retrieving revision 1.4
diff -u -p -r1.4 inaccessible
--- tests/rm/inaccessible       28 May 2006 12:11:35 -0000      1.4
+++ tests/rm/inaccessible       17 Jun 2006 07:19:27 -0000
@@ -15,6 +15,17 @@ t0=`echo "$0"|sed 's,.*/,,'`.tmp; tmp=$t
 trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 && exit $status' 0
 trap '(exit $?); exit $?' 1 2 13 15
 
+# Skip this test if your system has neither the openat-style functions
+# nor /proc/self/fd support with which to emulate them.
+skip=yes
+grep '^#define HAVE_OPENAT' $top_srcdir/config.h > /dev/null && skip=no
+test -d /proc/self/fd && skip=no
+
+if test $skip = yes; then
+  echo 1>&2 "$0: no openat support, so skipping this test"
+  exit 77
+fi
+
 framework_failure=0
 mkdir -p $tmp || framework_failure=1
 cd $tmp || framework_failure=1
@@ -30,7 +41,6 @@ fail=0
 p=$pwd/$tmp
 set +x
 (cd no-access; chmod 0 . && rm -r $p/abs1 rel $p/abs2) 2> out && fail=1
-test "$VERBOSE" = yes && set -x
 test -d $p/abs1 && fail=1
 test -d $p/abs2 && fail=1
 




reply via email to

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