Here's a strange bug that is starting to cause us lots of grief. Basically, by crawling down a large dirtree, I can manage to make CIFS "forget" a modified file, and stick to the old cached copy. This is an example, where /home/graphx/share is a mounted share: graphx@phentex:~$ md5sum share/Inventaire/test.txt 24888e516bec7aa0eacba52f5b3f6c37 share/Inventaire/test.txt Now I modify test.txt on the Windows box: graphx@phentex:~$ find share/Inventaire | wc -l 5132 graphx@phentex:~$ md5sum share/Inventaire/test.txt 24888e516bec7aa0eacba52f5b3f6c37 share/Inventaire/test.txt Although the timestamp has been updated accordingly, the contents is now the old version, and not what is currently on the remote share. If I umount/mount the share, things go back to normal, as the kernel has gotten rid of its cache when unmounting. (This leads me to believe that the bug is with the client, and not the server.) Without the previous find run, everything is fine. In fact, if I modify test.txt again and then run md5sum w/o find, the contents will be updated properly. (Unfortunately, I need to rsync the share, and can't very well do that while avoiding find, can I?) One interesting point is that this bug only occurs if the file size remains the same. (Filing this as critical, since this could easily lead to loss of data on a rw mount.)
I could easily reproduce this bug with Debian sarge kernel 2.6.8 / cifs 1.20. and a Windows 2003 server. I did see it even with just one subdir and one file. However when using vanilla kernel 2.6.9 / cifs 1.34 I didn't see it. (On the server I have always disabled oplocks and disabled offline files.)
This was fixed after version 1.20 (long before the current 1.35, and long before kernel 2.6.13)
Which is all well and good for 2.6 users, but those of us who prefer 2.4 are stuck with version 1.20c. I don't think it's fair to close this bug report until either a new version is released for 2.4, or the fix for this bug is backported to 1.20c. (Unless there is no longer any support for 2.4, in which case there should be some mention of this.)
I don't have much time to maintain the 2.4 version of cifs code but would help someone who wants to backport newer cifs code or fixes back to 2.4
What about this Bug? We are web-developper using a vmware-debian linux with samba-cifs, apache webserver and access to windows-shares with the web-files. We offen get the same problem an ohne a re-mount or server-restart solve it. Are there any ways to "sail round" this problem, may be deactivate caching? Thank you and best regards! Frank
(In reply to comment #5) > Are there any ways to "sail round" this problem, may be deactivate caching? Rumor has it that etch is just around the corner. :) After being bitten once more by this bug, I decided to take a swing at it. Given that this issue was reportedly fixed in 1.33, I backported the relevant changes to 1.22, which was the version included in 2.6.8. (Unfortunately, Bugzilla won't let me upload the patch at the moment. God I hate Bugzilla!)
Is this still an issue?
(In reply to comment #7) > Is this still an issue? Hi, i think it may be solved - i can't close it. Only the perfomance of cifs agains smb is the actualy problem :) But thies will be another task. Thanks for work!
> Is this still an issue? I wouldn't know, since I moved to 2.6 a long time ago. (And I no longer maintain that server anyway.) Feel free to do whatever you wish with this bug report.
should no longer be an issue