Re: coreutils-6.6 check failures on Itanium Linux

[Matthew Woehlke]

Bob Proulx wrote:
> Matthew Woehlke wrote:
> > I get two 'make check' test failures on Itanium Linux.
> > The tests are mv/dir2dir and mv/no-target-dir. The dir2dir failure
> > seems to be a disagreement on error message, although given that the
> > error I see is the same as on no-target-dir, I'm still suspicious.
>
> > < mv: cannot move `b/t' to `a/t': Device or resource busy
> > > mv: cannot move `b/t' to `a/t': Directory not empty
>
> Yes, both an error but different errors.  Can you reproduce the error
> from the command line?  It would probably make further debugging
> easier.

Yes, in fact I'd already tried that right after I saw the failure.
The interesting bits of strace:

access("a/t", W_OK) = 0
rename("b/t", "a/t") = -1 EBUSY (Device or resource busy)

> + mkdir -p d/sub empty src d2/sub e2
> + touch f
> + test 0 = 1
> + fail=0
> + mv -fT d empty
> mv: cannot move `d' to `empty': Device or resource busy
> + fail=1
>
> That seems really strange.  If I read that right it collapses to a
> very simple thing that should not be failing.
>
>   mkdir -p d/sub empty
>   $builddir/src/mv -fT d empty
>   strace -e file $builddir/src/mv -fT d empty
>
> The above works for me on my ia64 system.  That one looks to be the
> more interesting of the two failures.

Yes, agreed, and as mentioned I have no 'OS version' to test against, 
since /bin/mv does not understand -T. Anyway, strace said:

rename("d", "empty") = -1 EBUSY (Device or resource busy)

> I am using a 2.6 kernel.  I think that will be the big difference.
> But ia64 support really did not get stable in the linux kernel until
> 2.6 and so for ia64 I highly recommend upgrading.  This is very likely
> an ia64 specific kernel problem.

Yes, it probably is, however in this case upgrading is not an option. 
This is the kernel version on which we support our product (in fact, we 
don't officially support 2.6.x on ia64 at all). Given the likelihood of 
anyone needing this to actually work (since rm'ing the target first is 
always an option), I'm fine with skipping the test (with, as was 
suggested, preferably a big warning message :-)). I'll try to take a 
look at the test changes that were posted.

Hmm, how would you feel about doing something similar on buggy Darwin 
kernels? (I.e. detecting buggy kernels and skipping tests rather than 
having them fail?)

--
Matthew
Caution: keep out of reach of adults.