[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