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

[Jim Meyering]

Jim Meyering wrote:

> 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@".

Volker, you can diagnose this by stepping through ls.c's print_dir
function, doing "print *next" for each entry.
To be precise, do this:

  $ cd coreutils/src
  $ mkdir d && ln -s . d/s && chmod 600 d
  $ gdb --args ./ls --file-type d
  break readdir
  run
  fin
  next
  print *next
  continue
  fin
  next
  print *next
  continue
  fin
  next
  print *next
  continue

One of those three will be the entry for d/s (others are usually
"." and "..") and we care about the direct.d_type member.

I got this:

$4 = {
  d_ino = 1199615,
  d_off = 899204271,
  d_reclen = 24,
  d_type = 10 '\n',
  d_name = 
"s\000\025\025\n\031\372\022\000\000\000\000\000\377\377\377\177\000\000\000\000\030\000\004..\000\025\004",
 '\025' <repeats 227 times>

You can see that 10 corresponds to DT_LNK:

  (gdb) p (int)DT_LNK
  $5 = 10

Since the code appears to work as intended with DT_DIR, perhaps
your system (or file system) lacks DT_LNK support?