Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 73965 - ls silently fails on failing getdents64
ls silently fails on failing getdents64
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2002-09-13 11:44 EDT by diego.santacruz
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-22 10:00:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Strace log (7.14 KB, text/plain)
2002-09-13 11:46 EDT, diego.santacruz
no flags Details
New strace log under RedHat 8.0 (5.96 KB, text/plain)
2002-10-09 07:00 EDT, diego.santacruz
no flags Details
The ltrace log under RedHat 8.0 (2.56 KB, patch)
2002-10-09 07:01 EDT, diego.santacruz
no flags Details | Diff
Untested patch. (743 bytes, patch)
2002-10-09 07:09 EDT, Tim Waugh
no flags Details | Diff
ltrace output for "ls: .: Operation not supported" bug (5.65 KB, text/plain)
2002-11-06 20:34 EST, Bernie Innocenti
no flags Details

  None (edit)
Description diego.santacruz 2002-09-13 11:44:15 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:

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.
Comment 1 diego.santacruz 2002-09-13 11:46:23 EDT
Created attachment 76046 [details]
Strace log
Comment 2 Tim Waugh 2002-10-07 09:33:11 EDT
ls doesn't use this syscall directly; it uses opendir/readdir.  Does ltrace 
show glibc returning the right error code?
Comment 3 diego.santacruz 2002-10-09 06:57:40 EDT
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.
Comment 4 diego.santacruz 2002-10-09 07:00:13 EDT
Created attachment 79586 [details]
New strace log under RedHat 8.0
Comment 5 diego.santacruz 2002-10-09 07:01:14 EDT
Created attachment 79587 [details]
The ltrace log under RedHat 8.0
Comment 6 diego.santacruz 2002-10-09 07:04:01 EDT
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.
Comment 7 Tim Waugh 2002-10-09 07:09:52 EDT
Created attachment 79588 [details]
Untested patch.
Comment 8 Tim Waugh 2002-10-22 10:00:09 EDT
Fixed package is fileutils-4.1.9-12.
Comment 9 Bernie Innocenti 2002-11-06 20:28:50 EST
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.
Comment 10 Bernie Innocenti 2002-11-06 20:34:48 EST
Created attachment 83905 [details]
ltrace output for "ls: .: Operation not supported" bug

Note You need to log in before you can comment on or make changes to this bug.