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

Andrew Bartlett abartlet at samba.org
Mon Mar 18 14:53:01 MDT 2013


On Mon, 2013-03-18 at 13:40 -0700, Jeremy Allison wrote:
> On Mon, Mar 18, 2013 at 08:38:01PM +0100, Stefan (metze) Metzmacher wrote:
> > 
> > All tests have shown that it should make no difference if the client
> > send CAP_LARGE_READX or CAP_LARGE_WRITEX. Even if the client doesn't
> > send it, it's possible to do large reads and write.
> > 
> > If the client doesn't support large reads or write it would just doesn't
> > trigger them, there's really nothing more a client need to tell the server.
> > 
> > That's why we should should just skip this patch.
> 
> That's true for Samba clients to Windows servers. It's not
> true for Samba or MacOS clients to Samba servers 3.6.x or
> lower. In the v3-6-test code reply_read_and_X() we have:
> 
>        if (global_client_caps & CAP_LARGE_READX) {
>                 size_t upper_size = SVAL(req->vwv+7, 0);
> 
> - that's the only place we look at the upper bytes in
> a SMBReadX call. So yes, it does matter.
> 
> Both older Samba client libraries, MacOSX client, CIFSFS
> clients and jCIFS clients all correctly send (or not) the
> CAP_LARGE_READX bit on the sessionsetupX request from
> the client.
> 
> You changed that in the initial 4.0.x client code release.
> I think that was a mistake, and we need to put it back. It
> doesn't affect how Windows servers behave (or after we fix
> this code how Samba servers will behave), but it's the correct
> thing to do to inform servers (what they do with that knowledge
> is up to them).

I agree.  And given the mess we have got ourselves into here, the closer
we can get to Samba 3.6 behaviour on client and server (where we never
had any of this trouble) the better. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org




More information about the samba-technical mailing list