bug-coreutils
[Top][All Lists]
Advanced

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

Re: coreutils-8.3: test failed: ls/stat-dtype and touch/no-dereference


From: Jim Meyering
Subject: Re: coreutils-8.3: test failed: ls/stat-dtype and touch/no-dereference
Date: Fri, 08 Jan 2010 17:42:17 +0100

Eric Blake wrote:

> According to Voelker, Bernhard on 1/8/2010 7:40 AM:
>> Hello,
>>
>> `make check` failed for 2 of 357 tests here:
>>
>>   openSUSE 10.3 (X86-64) (inside a 1&1 hosted virtual machine)
>>   kernel 2.6.9-023stab051.3-smp
>>   gcc 4.2.1
>>   CPU: Quad-Core AMD Opteron(tm) Processor 2352
>
> Which glibc?
>
> Your kernel is quite old (it predates the utimensat syscall).  Assuming
> your glibc is new enough to provide the utimensat wrapper (which then
> fails with ENOSYS given the missing syscall), that would explain this failure:
>
>> FAIL: touch/no-dereference (exit: 1)
>> ====================================
>>
>> + grep '^#define HAVE_UTIMENSAT' /home/berny/depot/coreutils-8.3/lib/config.h
>> + touch -h dangling
>> touch: setting times of `dangling': Function not implemented
>
> The test is assuming that because glibc declared utimensat, that it will
> work.  But obviously it doesn't, because your kernel is too old.  I don't
> know of any better way to filter out this test, other than to add logic
> that skips (rather than fails) if touch dies with ENOSYS.

Sounds good to me.

>> FAIL: ls/stat-dtype (exit: 1)
>> =============================
> I'm not sure what's failing here; hopefully others can chime in.

The test first ensures that ls -p can determine that
the just-created c/d is a directory *without* calling stat:
(because it's in a directory, c/, that is not searchable)

    mkdir -p c/d || framework_failure
    chmod a-x c || framework_failure
    if test "X`ls -p c 2>&1`" != Xd/; then
      skip_test_ "'.' is not on a suitable file system for this test"
    fi

Your log output suggest that that works fine,
since the test was not skipped.

However, when we try to do the same thing with a symlink d/s
instead of a directory (and using --file-type instead of -p -- I don't
know off hand if that matters), it fails:

Here's code from the test script:

    ls --file-type d > out || fail=1
    cat <<\EOF > exp || fail=1
    s@
    EOF

Here's output from your log:

  + ls --file-type d
  ls: cannot access d/s: Permission denied
  + fail=1
  + cat
  + compare out exp
  + diff -u out exp
  --- out 2010-01-08 15:17:22.000000000 +0100
  +++ exp 2010-01-08 15:17:22.000000000 +0100
  @@ -1 +1 @@
  -s
  +s@
  + fail=1

It failed on two counts: first, ls exited nonzero.
Then the output, "s", did not match what was expected: "s@".




reply via email to

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