However, on one issue, they have really missed the boat. In order to gain speed, they have implemented a form of file caching. That is, the first time that you reference a file, on a Unix machine from a Windows machine, Samba retrieves the file and caches a copy of the file. The second time you reference the file, Samba returns the contents of the cache.
All that is fine and dandy, and file caching can result in significant performance improvements, but between the two references to your file from the Windows machine, if you just happen to update the file using Unix utilities, the next time you reference the file on the Windows system, you will get the old file. In other words, you get the wrong data.
Here is a quote from the Samba documentation:
Some people report problems with "cacheing" of data. Generally the bug report goes like this: - create a file on a unix box - view the file on a PC via Samba - change the file on the unix box - look at the file again on the PC via Samba and the changes are not visible The first thing to realise is that this is the expected behaviour! The SMB protocol uses a thing called "opportunistic locking". This allows the client to "safely" do client side cacheing of file data. The problem is that this cacheing is only safe if all programs access the files via SMB. As soon as you access the data via a non-SMB client then you will get data inconsistencies.
In some circumstances, I can see that this mode could be useful, if you are sure that there are no Unix modifications to files that you are going to be accessing more than once from Windows. However, this action is the default. This behavior caused me no end of grief until I realized that I was experiencing a Big Bad Bug.
If you repeat the above experiment, but substitute another Windows machine in place of the Linux machine, you never get "data inconsistencies". Thus, this can clearly be classified as a Big Bad Bug. I find it hard to believe that the Samba team made this decision -- speed is apparently more important to them than having Samba work 100% correctly!
One thing that I can say about the Samba team is that they have documented this problem and how to correct it. However, not all of us have the source code and documentation loaded.
If you are experiencing this problem, look at the smb.conf document for oplocks or veto oplocks, or look for the documentation on how to change the Windows registry to avoid this problem. Note, the DiscardCacheOnOpen variable is a DWORD rather than a STRING as the Samba documentation says.
Home: www.sibbald.com
Contact: kern at sibbald dot com
Last Update: