Chris de Vidal wrote: > > Still, wouldn't you welcome documentation advising > people of potential corruption? I think we both agree > that there is no guarantee that everyone's network is > 100% "on" and the danger of corruption appears to be > greater when there are large files read and written to > a record at a time (namely, flat databases).
I agree, and am getting together a better explanation of this problem to write up in Using Samba. (Hopefully, this will make it into the 2nd edition.) I was thinking of making the point that when oplocks are enabled, the client is really trusted to cache the file, and send back the updates when it receives the oplock break request. The integrity of the data is then much more dependent on the client working properly than in the non-oplock scenario. Since the clients are generally Windows systems, it should be understood that using oplocks carries an inherent additional risk for data integrity. Jeremy: does this sound ok? Or is it a little to cautious? And, if a (Windows) client is holding an oplock and it crashes or malfunctions, does that have the same effect as ignoring an oplock break request? Or is it worse? (I will also add a note saying that Samba is no different than Windows in its default behavior.) Jay Ts
