Bug 73877

Summary: ls with wildcard (e.g. ls *.txt) on NFS volumes fails
Product: [Retired] Red Hat Linux Reporter: Richard Bonomo <bonomo>
Component: tcshAssignee: Miloslav Trmač <mitr>
Status: CLOSED CURRENTRELEASE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: s.maass, sporring, unligil, unruh
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-17 13:08:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
additional tests for ls problem
compressed output ot strace command none

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/strace.ls.txt ls *.fits

in the directory where you tried "ls *.fits" before, and add the
/tmp/strace.ls.txt 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. ***