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 /usr/users/bonomo [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 alarm.ps barslet.ps beta1016.psh book.ps dumpster dumps.txt Epson_card_thanks Epson_gripe Epson_return fig2.ps ftpstuff.txt junk755par.ps.prn junk755.ps.prn junkmv4.ps.prn name.eps netscape.ps plpps plpstrp printcaps_all tps_base unix.ps upsbat2.txt from a volume served by RHL 7.x [bonomo@old-bob test]$ pwd /wisp/3/pboraw/test [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 pix: lens1.pix lens2.pix lens3.pix Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. (see description, above) 2. 3. Actual Results: see description above Expected Results: an accurate listing of files, appropriately filtered Additional info: see description above
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 show?
Created attachment 76067 [details] additional tests for ls problem
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, though.
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.
My fault, I missed a "csh" from the command line. Try: strace -f -o /tmp/csh.strace csh -c "ls *.fits"
Created attachment 76105 [details] compressed output ot strace command
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]$
It does look like a user-space bug. The strace shows: 2216 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 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.
Also, what does "ls -li" in this particular directory show?
Here are the results: [bonomo@old-bob ~]$ rpm -q tcsh tcsh-6.10-6 [bonomo@old-bob ~]$ rpm -q glibc glibc-2.2.5-39 [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]$
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 (rw,nosuid,nodev,_netdev,bg,intr,addr=144.92.179.32)
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): rw,hard,bg 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?
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.
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.
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.
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?
What is the status of a fix for this bug? Has it been resolved? Are patches available?
tcsh on Linux uses 64-bit file system calls since 6.12, this should be fixed in current releases.
*** Bug 30878 has been marked as a duplicate of this bug. ***
*** Bug 54186 has been marked as a duplicate of this bug. ***
*** Bug 55095 has been marked as a duplicate of this bug. ***
*** Bug 102698 has been marked as a duplicate of this bug. ***