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