Bug 73965 - ls silently fails on failing getdents64
Summary: ls silently fails on failing getdents64
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fileutils
Version: 8.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-09-13 15:44 UTC by diego.santacruz
Modified: 2007-04-18 16:46 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-10-22 14:00:21 UTC
Embargoed:

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

Description diego.santacruz 2002-09-13 15:44:15 UTC 
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.
Comment 1 diego.santacruz 2002-09-13 15:46:23 UTC 
Created attachment 76046 [details]
Strace log
Comment 2 Tim Waugh 2002-10-07 13:33:11 UTC 
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 10:57:40 UTC 
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 11:00:13 UTC 
Created attachment 79586 [details]
New strace log under RedHat 8.0
Comment 5 diego.santacruz 2002-10-09 11:01:14 UTC 
Created attachment 79587 [details]
The ltrace log under RedHat 8.0
Comment 6 diego.santacruz 2002-10-09 11:04:01 UTC 
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 11:09:52 UTC 
Created attachment 79588 [details]
Untested patch.
Comment 8 Tim Waugh 2002-10-22 14:00:09 UTC 
Fixed package is fileutils-4.1.9-12.
Comment 9 Bernie Innocenti 2002-11-07 01:28:50 UTC 
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-07 01:34:48 UTC 
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.