> -----Original Message----- > From: Green, Paul [mailto:Paul.Green@;stratus.com]
> My opinion is that the "right fix" is for anyone who is > experiencing data corruption of any sort, whether with oplocks on, off, or > sideways, to work with the Samba team to come up with a reproducible test case > so that we can root cause the true source of the problem. Then, we can > design and test some sort of fix, and no one else will ever have to worry about it. What I'm seeing from the Samba team is "this is a Windows client bug" or "this is an MS Access bug". I'm not saying they're wrong, but if that's the conclusion that's been reached wouldn't the rest of us just be wasting our time by trying to test this? The consensus seems to be that oplocks with Windows clients are simply broken by design. FWIW, I've never seen any corruption I could blame on Samba, with oplocks on, but my site only has 30 users, tops, and the most we ever had using the Access database simultaneously was five or six. (I did turn kernel oplocks off a couple months ago, but only because we don't need them -- nothing gets accessed from the UNIX side except during backups.) We actually saw more corruption in the Access database under Windows NT, but I blame this on a user who had a bad network connection that we discovered about the time we switched to Samba. This would tend to back up the theory that dropped packets aggravate this problem. It's rather shocking to me that SMB reacts to poorly to network problems, but I realize there's not much Samba can do about the crummy protocol design. ;)
