From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020606
Description of problem:
Apparently ls does not check the return code of the getdents64 syscall. I have a
case were getdents64() fails and yet ls displays an empty directory and exits
with code 0.
Version-Release number of selected component (if applicable): fileutils-4.1-4
Steps to Reproduce:
1. do ls on a troublesome directory (problematic NFS in this case)
2. getdents64 syscall fails
3. ls reports no error and exits with code 0
Actual Results: empty directory listing and exit code 0
Expected Results: an error message and a non-zero exit code
The getdents64 is failing because of a troublesome NFS mount. But ls should
report the failing syscall.
I'll attach the strace output next.
Created attachment 76046 [details]
ls doesn't use this syscall directly; it uses opendir/readdir. Does ltrace
show glibc returning the right error code?
In the meantime I upgraded to RedHat 8.0 with fileutils-4.1.9-11. The problem
still persists. The new strace/ltrace logs coming.
Created attachment 79586 [details]
New strace log under RedHat 8.0
Created attachment 79587 [details]
The ltrace log under RedHat 8.0
From the ltrace log, it appears as if ls is ignoring the fact that readdir() can
return NULL on end-of-file or error and is not checking the errno, or that errno
is not correctly set by glibc.
Created attachment 79588 [details]
Fixed package is fileutils-4.1.9-12.
The new package (fileutils-4.1.9-12) shows this on my system:
# mkdir /foo
# touch /foo/bar
# ls -l /foo
ls: /foo: Operation not supported
-rw-r--r-- 1 root root 0 Nov 7 02:20 bar
(return code is 1)
Apparently, any directory containing at least one file is enough to trigger
this problem. It happens both with kernel 2.4.19-0.pp.4 and 2.4.18-17. It also
happens with any filesystem (tested on /proc). The previous version of
fileutils (fileutils-4.1.9-11) was fine.
Created attachment 83905 [details]
ltrace output for "ls: .: Operation not supported" bug