ls and ls -l disagree

Dr Gareth J. Barker gbarker at mph.sm.ucl.ac.uk
Tue Aug 14 19:32:29 AEST 1990


Can anyone explain the following discrepancy between the output of ls and
ls -l on an NFS mounted file system with client and server both running
4.1?

First, sitting on the mount point (/mounts/reo0) just after mounting the
file system:

titan# /bin/ls
bev         lost+found
titan# /bin/ls -l
lost+found not found 
bev not found
total 0

    ^^^^^^^^^^^^^^^^

Now, moving up one directory:

titan# cd ..
titan# ls
fd0   reo0  reo1
titan# ls *
fd0:

reo0:
bev         lost+found

reo1:
titan# ls -l *
fd0:
total 0

reo0:
total 9
drwxr-xr-x  2 100           512 Feb 26 16:44 bev
drwxr-xr-x  2 100          8192 Feb 26 16:34 lost+found

reo1:
total 0

And finally moving back where we were originally:

titan# cd reo0
titan# ls -l
total 9
drwxr-xr-x  2 100           512 Feb 26 16:44 bev
drwxr-xr-x  2 100          8192 Feb 26 16:34 lost+found

The mount has some non-standard mount options (to tryto allow for the slow
speed of the optical disk  that the filesystem is physically on):

titan# mount
saturn:/export/root/titan on / type nfs (rw)
<edited>
saturn:/mounts/reo0 on /mounts/reo0 type nfs (bg,rw,hard,wsize=2048,intr,timeo=20)
titan# 

Can these be affecting ls and ls -l differently ('cos of caching??) Thanks
for any help

Gareth J. Barker,
Institute of Neurology, Queen Square,
London, UK.

JANET    : gbarker at uk.ac.ucl.sm.mph
INTERNET : gbarker at .mph.sm.ucl.ac.uk
BITNET   : gbarker%uk.ac.ucl.sm.mph at ukacrl.bitnet



More information about the Comp.sys.sun mailing list