[linux-cifs-client] Hello, and possible problem (stale client-side cache)

Vince Negri vnegri at asl-electronics.co.uk
Wed Jan 12 15:40:28 GMT 2005


Hi all,

A recent upgrade to our network (win2k3 AD servers)
has necessitated replacing smbfs with cifs on several
Linux boxen.

Most of the machines are 2.4.xx based, and for these 
I obtained the latest 1.20c tarballs. No problems
with build, installation or configuration, but there
is a recurring problem which I have now reproduced
on a 2.6 kernel machine which had CIFs "out of the box"
(but version 1.18)

The problem is as follows:

1) Shared directory on the Win2k3 server mounted using
mount.cifs, no special options
(user=xx,uid=xx,gid=users)

2) User 'xx' can access/write to/create files no problem.

3) Linux client has already read contents of a file "foo.c",
say in the course of a compile.

3) On another machine, a windows client alters file "foo.c"
by adding or removing lines.

4) foo.c shows up correctly in "ls -l" with new file size
and file time.

5) However, a command like "vi foo.c" ends up loading a file
with the *old data* but the *new length*. If the file has been
shortened on the server, one usually gets binary zeroes on the end
of the file.



Usually, if the windows client then updates the file a second time,
this sorts it out by provoking the linux cifs client to invalidate
its local cache.

I haven't seen anything in the latest CHANGES file that relates to
this, all the caching bugs were many versions ago.

I have tried disabling LookUpCacheEnabled and OplockEnabled, just in
case, but to no avail.

I'm happy to try fiddling with the module source and testing things.
Is there anywhere to start looking, or is this an issue which has
been run into before (and I need to backport something from the 2.6
branch?)


Vince




Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this 
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such 
privilege. Please advise the sender if you receive this e-mail by mistake.



More information about the linux-cifs-client mailing list