| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
Here's something odd when run on a remote NFS disk: smchip.pa.dec.com> ls -al 28* -rw------- 1 pdonahue staff 1897 Mar 25 17:27 28 -rw------- 1 pdonahue staff 884 Mar 25 17:27 280 -rw------- 1 pdonahue staff 710 Mar 25 17:27 281 -rw------- 1 pdonahue staff 2287 Mar 25 17:27 282 smchip.pa.dec.com> ls -al 283 284 285 -rw------- 1 pdonahue staff 1648 Mar 25 17:27 283 -rw------- 1 pdonahue staff 1064 Mar 25 17:27 284 -rw------- 1 pdonahue staff 2060 Mar 25 17:27 285 smchip.pa.dec.com> df . Filesystem 1024-blocks Used Available Capacity Mounted on clayct:/padc_u2 4061956 1742522 1913238 48% /tmp_mnt/r/padc_u2 How come the wildcard doesn't pick up the other files which are actually there? When I run on the NFS server it works fine: clayct.pa.dec.com> ls -al 28* -rw------- 1 pdonahue staff 1897 Mar 25 17:27 28 -rw------- 1 pdonahue staff 884 Mar 25 17:27 280 -rw------- 1 pdonahue staff 710 Mar 25 17:27 281 -rw------- 1 pdonahue staff 2287 Mar 25 17:27 282 -rw------- 1 pdonahue staff 1648 Mar 25 17:27 283 -rw------- 1 pdonahue staff 1064 Mar 25 17:27 284 -rw------- 1 pdonahue staff 2060 Mar 25 17:27 285 -rw------- 1 pdonahue staff 789 Mar 25 17:27 286 -rw------- 1 pdonahue staff 1662 Mar 25 17:27 287 -rw------- 1 pdonahue staff 832 Mar 25 17:27 288 -rw------- 1 pdonahue staff 1984 Mar 25 17:27 289 I have tried on other machines that NFS mount that disk and they all seem to see the full set of files. It is only smchip that stops at 282. The smchip machine clearly can access 283 since I can "cat" it from that machine, but the wildcarding in tcsh doesn't see 283 and higher. Is this an NFS bug or a shell bug? I tried with tcsh and with sh and got the same results. This behavior is not a glitch in NFS caching that disappears a few seconds later. This has been 100% reproducible for days (and the server has even been rebooted during that time). This is in one of my mail directories, so mh is acting very strangely since the files exist and my workstation doesn't see them when wildcarded, but does when they are specifically named. Thanks, -Paul
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9389.1 | NABETH::alan | Dr. File System's Home for Wayward Inodes. | Thu Apr 03 1997 22:14 | 4 | |
What version is the offending system? I've seen some odd wildcard expansion bugs in the V4.0 csh(1). I submitted QAR #47019 on the subject some months ago. My problem may have been specific to grep though. | |||||
| 9389.2 | Wildcard expansion problems in V4.0 csh | DECC::SULLIVAN | Jeff Sullivan | Fri Apr 04 1997 13:54 | 13 |
I agree with .1 that there is/was a problem in wildcard expansion in csh over NFS filesystems. I also reported an OSF_QAR (I think it was 48526). One workaround that I used was to spawn a Bourne shell (korn may also work) and do the command I needed. I even converted some C-shell scripts to Bourne to get around the problem. We received a patched C-shell a while ago and it appears to resolve the problem. I know that it was not fixed in V4.0, but hopefully it is in V4.0A and later. -Jeff | |||||
| 9389.3 | Not specific to one shell | PADC::PDONAHUE | Paul Donahue | Fri Apr 04 1997 17:29 | 40 |
The same problem exists with tcsh (my default), csh, sh, and ksh. Here's an exact transcript of using all three. It appears to definitely be a wildcard problem, but it's strange that it happens on all four shells. I also did an emacs dired on that directory and emacs doesn't see above 282, either. Thanks, -Paul smchip.pa.dec.com> cd ~/Mail/sa110 smchip.pa.dec.com> ls -al 28* -rw------- 1 pdonahue staff 1897 Mar 25 17:27 28 -rw------- 1 pdonahue staff 884 Mar 25 17:27 280 -rw------- 1 pdonahue staff 710 Mar 25 17:27 281 -rw------- 1 pdonahue staff 2287 Mar 25 17:27 282 smchip.pa.dec.com> ls -al 283 284 -rw------- 1 pdonahue staff 1648 Mar 25 17:27 283 -rw------- 1 pdonahue staff 1064 Mar 25 17:27 284 smchip.pa.dec.com> sh $ ls -al 28* -rw------- 1 pdonahue staff 1897 Mar 25 17:27 28 -rw------- 1 pdonahue staff 884 Mar 25 17:27 280 -rw------- 1 pdonahue staff 710 Mar 25 17:27 281 -rw------- 1 pdonahue staff 2287 Mar 25 17:27 282 $ exit smchip.pa.dec.com> ksh $ ls -al 28* -rw------- 1 pdonahue staff 1897 Mar 25 17:27 28 -rw------- 1 pdonahue staff 884 Mar 25 17:27 280 -rw------- 1 pdonahue staff 710 Mar 25 17:27 281 -rw------- 1 pdonahue staff 2287 Mar 25 17:27 282 $ exit smchip.pa.dec.com> csh -f % ls -al 28* -rw------- 1 pdonahue staff 1897 Mar 25 17:27 28 -rw------- 1 pdonahue staff 884 Mar 25 17:27 280 -rw------- 1 pdonahue staff 710 Mar 25 17:27 281 -rw------- 1 pdonahue staff 2287 Mar 25 17:27 282 % exit | |||||
| 9389.4 | QAR 52369 entered | PADC::PDONAHUE | Paul Donahue | Fri Apr 04 1997 18:10 | 6 |
I entered this as a QAR, number 52369. It seems to me to be an NFS client bug since it's not shell-specific and the server seems to be serving the other clients on our network with no problem. -Paul | |||||