[Multipart nttrans replies 3/3] Take 4: multi-part nttrans replies

Sam Liddicott sam at liddicott.com
Sat Jul 5 07:15:10 GMT 2008

I remember why I didn't want to actually receive the response in the handler.

For most requests, the receive buffer (in the smb_* struct) is pre-allocated by the caller, and for vfs_cifs and vfs_proxy they are pre-allocated in the partially constructed response packet, and so memcpy and stuff can be avoided, so effectively io->out.data is an input argument.

Thus it is not generally possible or worthwhile to receive the response unless the callers io struct is available.

But I did not check to see if that was specifically true for the cases that need multi-part responses, and it seems not to be the case but I'l check when I have a screen resolution of more than 320x240.

This helper mechanism is simplified to naturally suit operations that don't pre-allocate a data buffer for the response.

There may not be other types that also need a helper, but it ought to be commented I think.


-----Original Message-----
From: Sam Liddicott <sam at liddicott.com>
Sent: 05 July 2008 07:40
To: Stefan (metze) Metzmacher <metze at samba.org>
Cc: samba-technical <samba-technical at lists.samba.org>
Subject: RE: [Multipart nttrans replies 3/3] Take 4: multi-part nttrans replies

You beat me.
I did think of actually receiving the response in the helper, just not for very long.

I also missed clearing the req->in after each part.

Thanks for looking over that and for the better job of it.


-----Original Message-----
From: Stefan (metze) Metzmacher <metze at samba.org>
Sent: 04 July 2008 20:10
To: Sam Liddicott <sam at liddicott.com>
Cc: samba-technical <samba-technical at lists.samba.org>
Subject: Re: [Multipart nttrans replies 3/3] Take 4: multi-part nttrans replies

Sam Liddicott schrieb:
> This patch allows smb_raw_nttrans_recv to handle multi-part responses
> even when used asynchronously from a callback.

I'll commit a different approach to fix this problem,
it'll change much less of the core code and has less potential
to bugs in the recv helpers.

here's the branch:


More information about the samba-technical mailing list