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

Andrew Bartlett abartlet at samba.org
Fri Mar 15 02:09:34 MDT 2013


On Thu, 2013-03-14 at 09:10 -0700, Jeremy Allison wrote:
> On Thu, Mar 14, 2013 at 04:10:22PM +1100, Andrew Bartlett wrote:
> > 
> > The reason I would like it removed it that then the client side, not
> > needing to trigger/not trigger the magic 'samba' detection, totally
> > controls if the server thinks large reads/writes are acceptable.
> 
> That's exactly as it should be.
> 
> Our server *always* thinks large reads are acceptable, that's
> how it's coded.
> 
> It's completely up to the client to determine whether it wishes
> to ask for them or not.

Sure.  What I'm getting at is that the last server that 'just worked'
was Samba 3.6, where reply.c has no 

if (get_remote_arch() == RA_SAMBA) {

statement.  I'm still advocating that we should return to that state. 

I understand you concern about 4.0.x clients, but what exactly will they
do wrong, that they don't already do against Windows, except be a bit
slower until patched?

> > Otherwise, how does your test show we behave correctly for clients that
> > don't advertise this capability, but do (wrongly) ask for a large
> > read?  
> 
> The only "wrong" way to ask for a large read is to set the upper
> bytes to 0xFFFF and set CAP_LARGE_READX. My test covers that
> case, and the patchset also fixes the server to behave the correct
> way in response (i.e. to explicitly ignore the upper bytes when
> they're set to 0xFFFF, as the tech note in the spec says).

How do you test the 'if (get_remote_arch() == RA_SAMBA) {' codepath?

Thanks,

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




More information about the samba-technical mailing list