Is the ls command output cached? Any docs to verify?

[Jason Cannon]

Several times recently I've copied (newer) files over existing files and I immediately see the results with ls. When I say, "I'm done, the new file is in place," the user repeats the ls command and sees the old file. After repeated runs of ls the new file shows up about a minute or so later for the end user.

I'm almost certain that the output of the ls command is cached but I haven't found any documentation to verify my claim. (I can see the same situation with find... the first time you run find it chugs through the files on the disk and if I repeat the find command immediately I get an instant result.)

Can anyone point me to the documentation that explains this and verifies my claim? My users (are starting to) think I'm crazy! Ha!

Thanks!

Jason

[RAC_1]

timex ls

copy files

timex ls

This certainly is not a full proof methos, but looks like will give some idea. The second iteration of ls will take less than first one.

Anil

[Steven E. Protter]

I'd like to see the details of your test.

I've never seen that kind of behavior on an HP-9000 server doing tests similar to that.

I could make it happen only by running the copy command in the background. Then i would not see results until the command was done executing.

Now if your end user is using a MICROSOFT opererating system, those are known to do things like that. Also if the change has occured after a CIFS user already has a folder on Unix open, they would have to refresh or they'd see old results. If the copy had happened prior to refresh and say filea was gone and they tried to access it, access should fail.

I can't find documentation, I can only provide experience and say I've run similar tests to the first response to your thread, those few times I thought what you say is happening was happening.

SEP

[RAC_1]

Few more things came to my mind, what file systems is this??
What options are used to mount it??

Are users doing ls on same machine, or ono nfs point?? Details please.

Anil

[A. Clay Stephenson]

Ls does not cache. You can prove this to yourself by copying several large files in the backgroud or another session. Repeated ls -l commands will show the file size changing.

Your find example is rather bogus as well. The second "quick" run of find is the result of UNIX buffer caching. After the first run, if the command is quickly repeated there is an extremely high probability that many (most) of the disk blocks are still in the buffer cache so that only a few (possibly zero) disk accesses are required.

[A. Clay Stephenson]

There is one exception to this although ls itself doesn't cache. If this is an NFS mountpoint then there is some caching of file metadata to reduce network traffic. Man mount_nfs and look at the acdirmin and acregmin to see if these mount options apply.

[Jason Cannon]

Details:

HP-UX 11.00
vxfs
Using automounter, but files are all local to the box in this example. (Ie, /opt/proggy mounts /export/opt/proggy.)
Doing copy to /opt/proggy/XYZ and ls in the same place.

Thanks!

Jason