Red Hat Bugzilla – Bug 73965
ls silently fails on failing getdents64
Last modified: 2007-04-18 12:46:40 EDT
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 How reproducible: Always 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 Additional info: 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] Strace log
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] Untested patch.
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 total 0 -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