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?
