Reproducible Data Corruption Issue

[Jeremy Allison]

On Thu, Oct 09, 2014 at 08:21:53PM +0200, Volker Lendecke wrote:
> On Thu, Oct 09, 2014 at 09:16:42AM -0700, Jeremy Allison wrote:
> > 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.
> 
> I'd call this some unexpected behaviour (bug) of the Linux cifs client
> with Samba. My understanding of the document is that the target file is
> only being accessed via Samba, both ftp clients come in via a Linux cifs
> mount. If that is a misunderstanding on my side, please correct me.
> 
> I believe this *should* work and not cause corruption. It would be
> interesting to me to see the full logs and network traces, if possible
> together with an strace -ttT of both ftp server processes.

Oh, if that is the case then I'm being stupid, and it
should certainly work :-).

Jeremy.