Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 73877 - ls with wildcard (e.g. ls *.txt) on NFS volumes fails
Summary: ls with wildcard (e.g. ls *.txt) on NFS volumes fails
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tcsh
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Ben Levenson
: 30878 54186 55095 102698 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-09-12 20:19 UTC by Richard Bonomo
Modified: 2007-04-18 16:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-08-17 13:08:11 UTC

Attachments (Terms of Use)
additional tests for ls problem (deleted)
2002-09-13 17:39 UTC, Richard Bonomo
no flags Details
compressed output ot strace command (deleted)
2002-09-13 18:49 UTC, Richard Bonomo
no flags Details | Diff

Description Richard Bonomo 2002-09-12 20:19:52 UTC
From Bugzilla Helper: 
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux) 
Description of problem: 
If you use the "*" wildcard with ls (even simply ls *) on an NFS mounted 
volume in a directory with a substantial number of file 
entried, you get a "no match" response (seen with files served 
by SGI IRIX 6.5.x).   ls * on NFS volumes served by RHL 7.x will 
not show non-directory files in the directory from which ls is executed, and  
ls *.<something> does not produce the correct output. 
Here is some sample output: 
from a volume served by SGI IRIX 6.5.x: 
[bonomo@old-bob ~]$ pwd 
[bonomo@old-bob ~]$ ls * 
ls: No match. 
[bonomo@old-bob ~]$ ls *.txt 
ls: No match. 
[bonomo@old-bob ~]$ ls *.ps 
ls: No match. 
[bonomo@old-bob ~]$ ls | grep .ps 
from a volume served by RHL 7.x 
[bonomo@old-bob test]$ pwd 
[bonomo@old-bob test]$ ls 
blue500.imh    img00629.fits  img00636.fits  img01690.fits  red500.imh 
blue600.imh    img00630.fits  img00637.fits  img01691.fits  red600.imh 
blue700.imh    img00631.fits  img01685.fits  lens1.imh      red700.imh 
blue800.imh    img00632.fits  img01686.fits  lens2.imh      red800.imh 
blue825.imh    img00633.fits  img01687.fits  lens3.imh      red825.imh 
bluefoc.log    img00634.fits  img01688.fits  logfile        redfoc.log 
img00625.fits  img00635.fits  img01689.fits  pix            test.imh 
[bonomo@old-bob test]$ ls *.fits 
ls: No match. 
[bonomo@old-bob test]$ ls * 
blue500.imh  blue800.imh  lens1.imh  red500.imh  red800.imh  test.imh 
blue600.imh  blue825.imh  lens2.imh  red600.imh  red825.imh 
blue700.imh  bluefoc.log  lens3.imh  red700.imh  redfoc.log 
lens1.pix  lens2.pix  lens3.pix 
Version-Release number of selected component (if applicable): 
How reproducible: 
Steps to Reproduce: 
1. (see description, above) 
Actual Results:  see description above 
Expected Results:  an accurate listing of files, appropriately filtered 
Additional info: 
see description above

Comment 1 Stephen Tweedie 2002-09-13 16:32:19 UTC
What does "strace" show for these attempts?  For example, try 

  strace -o /tmp/ ls *.fits

in the directory where you tried "ls *.fits" before, and add the
/tmp/ output as an attachment to this bugzilla report.

This really looks more like an odd "ls" setup than anything else.  Does it work
exactly as expected on non-NFS dirs?  What does the command

  type ls


Comment 2 Richard Bonomo 2002-09-13 17:39:22 UTC
Created attachment 76067 [details]
additional tests for ls problem

Comment 3 Stephen Tweedie 2002-09-13 17:57:16 UTC
Looks like a csh problem.  To confirm what might be happening, please try this:

   strace -f -o /tmp/csh.strace -c "ls *.fits"

and compress and attach the /tmp/csh.strace file (it will probably be 400 or
500K long uncompressed.)  I've tried it on an NFS system here with no problems,

Comment 4 Richard Bonomo 2002-09-13 18:28:22 UTC
 Attempted your request test.  It gets clobbered at the starting gate: 
[bonomo@old-bob test]$ strace -f -o /tmp/csh.strace -c "/bin/ls *.fits" 
strace: /bin/ls *.fits: command not found 
[bonomo@old-bob test]$ ls -l /tmp/csh* 
-rw-r--r--    1 bonomo   root            0 Sep 13 13:23 /tmp/csh.strace 
I DO get an output file is I omit the "*.fits" from the ls command.

Comment 5 Stephen Tweedie 2002-09-13 18:34:01 UTC
My fault, I missed a "csh" from the command line.  Try:

  strace -f -o /tmp/csh.strace csh -c "ls *.fits"

Comment 6 Richard Bonomo 2002-09-13 18:49:39 UTC
Created attachment 76105 [details]
compressed output ot strace command

Comment 7 Richard Bonomo 2002-09-13 18:51:08 UTC
Here is command line input/output: 
[bonomo@old-bob test]$ strace -f -o /tmp/csh.strace csh -c "ls *.fits" 
Process 2200 attached 
Process 2201 attached 
Process 2201 detached 
Process 2202 attached 
Process 2202 detached 
Process 2203 attached 
Process 2203 detached 
Process 2200 detached 
Process 2204 attached 
Process 2204 detached 
Process 2205 attached 
Process 2205 detached 
Process 2206 attached 
Process 2206 detached 
Process 2207 attached 
Process 2207 detached 
Process 2208 attached 
Process 2208 detached 
Process 2209 attached 
Process 2210 attached 
Process 2211 attached 
Process 2210 detached 
Process 2211 detached 
Process 2209 detached 
Process 2212 attached 
Process 2213 attached 
Process 2213 detached 
Process 2212 detached 
Process 2214 attached 
Process 2215 attached 
Process 2215 detached 
Process 2214 detached 
Using dummy cshrc.sal 
Process 2216 attached 
ls: No match. 
Process 2216 detached 
[bonomo@old-bob test]$ 

Comment 8 Stephen Tweedie 2002-09-13 20:32:35 UTC
It does look like a user-space bug.  The strace shows:

2216  fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
2216  fcntl64(3, F_SETFD, FD_CLOEXEC)   = 0
2216  getdents64(0x3, 0x80d6c38, 0x1000, 0) = 1392
2216  _llseek(3, 2094777627, [2094777627], SEEK_SET) = 0
2216  getdents64(0x3, 0x80d6c38, 0x1000, 0) = 712
2216  close(3)                          = 0

and that is illegal; you can't call _llseek on a directory in that way. 
However, I don't see that behaviour on a local 7.3 test system.  What version of
csh and glibc are you using?  "rpm -q tcsh" and "rpm -q glibc" to see.

Comment 9 Stephen Tweedie 2002-09-13 20:39:00 UTC
Also, what does "ls -li" in this particular directory show?

Comment 10 Richard Bonomo 2002-09-13 20:44:47 UTC
Here are the results: 
[bonomo@old-bob ~]$ rpm -q tcsh 
[bonomo@old-bob ~]$ rpm -q glibc 
[bonomo@old-bob test]$ ls -li 
total 6620 
21102780 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 blue500.imh 
21102781 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 blue600.imh 
21102784 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 blue700.imh 
21102785 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 blue800.imh 
21102786 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 blue825.imh 
21102787 -rw-r--r--    1 khn      pbo          1889 Jul  3  1996 bluefoc.log 
21102788 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00625.fits 
21102798 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00629.fits 
21102800 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00630.fits 
21102801 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00631.fits 
21102802 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00632.fits 
21102803 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00633.fits 
21102804 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00634.fits 
21102805 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00635.fits 
21102806 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00636.fits 
21102807 -rw-r--r--    1 khn      pbo        132480 Jul  3  1996 img00637.fits 
21103750 -rw-r--r--    1 khn      pbo        757440 Nov  1  1996 img01685.fits 
21102799 -rw-r--r--    1 khn      pbo        757440 Nov  1  1996 img01686.fits 
21103753 -rw-r--r--    1 khn      pbo        757440 Nov  1  1996 img01687.fits 
21103754 -rw-r--r--    1 khn      pbo        757440 Nov  1  1996 img01688.fits 
21102789 -rw-r--r--    1 khn      pbo        757440 Nov  1  1996 img01689.fits 
21102794 -rw-r--r--    1 khn      pbo        757440 Nov  1  1996 img01690.fits 
21102795 -rw-r--r--    1 khn      pbo        757440 Nov  1  1996 img01691.fits 
21103747 -rw-r--r--    2 khn      pbo          8048 Nov  1  1996 lens1.imh 
21103749 -rw-r--r--    2 khn      pbo          8048 Nov  1  1996 lens2.imh 
21103748 -rw-r--r--    2 khn      pbo          8048 Nov  1  1996 lens3.imh 
21102810 -rw-r--r--    1 khn      pbo             0 Jul  3  1996 logfile 
25165959 drwxr-xr-x    2 khn      pbo            63 Nov  1  1996 pix 
21102811 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 red500.imh 
21102812 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 red600.imh 
21102813 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 red700.imh 
21102814 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 red800.imh 
21102815 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 red825.imh 
21103745 -rw-r--r--    1 khn      pbo          1804 Jul  3  1996 redfoc.log 
21103746 -rw-r--r--    1 khn      pbo          8048 Jul  3  1996 test.imh 
[bonomo@old-bob test]$ 

Comment 11 Richard Bonomo 2002-10-16 21:18:23 UTC
Has there been any movement on this issue? 
For what it is worth, here is a pertinent line from /etc/fstab: 
harlan:/wisp/3 on /wisp/3 type nfs  

Comment 12 Richard Bonomo 2002-10-16 21:29:44 UTC
I examined a system in another department, and I saw they were not having 
this problem.  I checked their /etc/fstab files and saw that they were 
mounting their nfs volumes using these options, instead of the ones I 
employed (which I understood to be the recommended ones): 
I switched one one my /etc/fstab entries to this, and with these 
options the problem I described does not (so far -- I haven't done 
a thorough check yet) occur.  Can someone explain this to me?  Which 
set of options is to be preferred for nfs mounts? 

Comment 13 Richard Bonomo 2002-10-16 22:21:28 UTC
 Belay last remark.  The changes do not make the problem go away on our 
system; they simply change it a bit.  It will allow some filtering if 
a VERY small number of files is involved.

Comment 14 Richard Bonomo 2002-10-16 23:06:24 UTC
 Sorry for so many new notes in such a short time, but this bug is going 
to be a major pain pretty soon, as our transistion to Linux continues.  
Anyway: In case I failed to note it before, this problem does not occur 
if one does an ls -l *.<string> from one of our SGI workstations (IRIX 6.5.x) 
also using csh, in the directory being served by the Linux box.  This appears 
to be a problem only if ls is excecuted on a Linux box.

Comment 15 Stephen Tweedie 2002-11-11 20:58:49 UTC
The underlying problem here is that the readdir() system call is deprecated ---
it is a 32-bit call, and simply cannot encode the 64-bit cookies which some
NFSv3 servers (especially IRIX) produce.

csh needs to open the directory with O_LARGEFILE and use readdir64() when
pulling down directory entries for globbing.  That's why bash works --- it
already uses readdir64.

Comment 16 Richard Bonomo 2003-02-17 22:16:00 UTC
Hello!  I have not heard anything about this in quite some time.  If the 
cause is known, why hasn't an appropriately patched version of csh been 
made available as a patch via update and/or directly.  Is there something 
preventing this, or is this simply a more complicated matter than it seems? 

Comment 17 Richard Bonomo 2003-08-21 19:28:05 UTC
What is the status of a fix for this bug?  Has it been resolved?  Are patches available?

Comment 18 Miloslav Trmač 2004-08-17 13:08:11 UTC
tcsh on Linux uses 64-bit file system calls since 6.12,
this should be fixed in current releases.

Comment 19 Miloslav Trmač 2004-08-17 13:09:38 UTC
*** Bug 30878 has been marked as a duplicate of this bug. ***

Comment 20 Miloslav Trmač 2004-08-17 13:11:48 UTC
*** Bug 54186 has been marked as a duplicate of this bug. ***

Comment 21 Miloslav Trmač 2004-08-17 13:12:56 UTC
*** Bug 55095 has been marked as a duplicate of this bug. ***

Comment 22 Miloslav Trmač 2004-08-17 13:58:46 UTC
*** Bug 102698 has been marked as a duplicate of this bug. ***

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