Reproducible Data Corruption Issue

[Jeremy Allison]

On Wed, Oct 08, 2014 at 04:46:53PM +0000, Green, Paul wrote:
> Gentle Samba Developers,
> 
> A customer of Stratus recently reported a data corruption issue to us that we have tracked back to Samba. We've been able to reproduce it using multiple versions of Samba on two different operating systems. We can easily reproduce the problem and can supply traces. We're seeking guidance on whether this is a code issue or a configuration issue. (I suspect a code issue, for reasons explained in the memo).
> 
> The attached memo supplies the full details. Feel free to contact me for further information.
> 
> P.S. The link on www.samba.org/samba/ml-etiquette.html<http://www.samba.org/samba/ml-etiquette.html> for "List Subscribe" points to https://lists.samba.org. The link fails. Using http://lists.samba.org works. This confusion between https and http seems to be a common problem with links to lists.samba.org, actually.

Hi Paul,

Looking at this report in more detail, it looks like
the (extremely rare) case of accessing a
file using 2 protocols simultaneously,
the protocols being CIFS and ftp.

If you're doing this:

1). Turn off oplocks. You need to
set "oplocks = no" on that share
if you expect to see *any* consistency
between the ftp client and the Linux
CIFS client. Otherwise all bets are
off (the Linux CIFS client code will
cache up the wazoo, which is what
the report seems to be complaining
about :-).

2). The report seems to be expecting
fcntl byte range locks to save them.
ftp clients don't issue byte range
lock requests - they ignore them.

If you need true cross-protocol
synchronization, turn off oplocks
and ensure the byte ranges you're
accessing are locked by *both*
protocols.

IMHO this doesn't look like a
Samba bug, but a config (and
expectations) error.

Feel free to prove me wrong and
point out my mistakes :-).

Jeremy.