[PATCH] Fix for bug #9706 - Parameter is incorrect on Android

[Jeremy Allison]

On Thu, Mar 14, 2013 at 04:15:37PM +0100, Stefan (metze) Metzmacher wrote:
> Hi Jeremy,
> 
> >>> Please review (and test :-) and push if you're happy.
> >>
> >> Can you write some tests which verifies both patches?
> > 
> > Ok, here is the patchset I've attached to the bug.
> > Applies cleanly to 4.0.next.
> > 
> > It includes a new test suite, LARGE_READX which tests around the boundaries of
> > large readX calls with read requests of:
> > 
> > 0xFFFF0001 (which should return 1 byte).
> > 0x10000 (which should always return 0x10000)
> > 0x1FFFF (which returns 0x1FFFF on Samba, and 0x10000 on Windows)
> > 0x100000 (which returns 0x100000 on Samba, and 0x10000 on Windows).
> 
> What are the results without LARGE_READX announced from the client?

Exactly the same for Windows. It simply ignores LARGE_READX
announced from the client and truncates all reads at 0x10000.

> I think Samba should return the same as Windows,
> except when they're talking a different protocol (unix extentions) to
> the client.
> 
> For SMB1 (without unix extentions) the largest transport message be
> 0x1FFFF (including the header).

Except that Windows ignores that, and will return only 0x10000 for
any read request of 0x10000 or larger.

That is simply broken, and we should not return the same as
Windows.

That will also break the MacOSX client (again) which only
sets CAP_LARGE_READX and does not tell us it's using the
UNIX extensions protocol, only queries it.

I have spent quite a lot of time investigating this, and
I'd appreciate some reasonable consideration of the patch
please.

Jeremy.