smbcli connection using public libs only

Volker Lendecke Volker.Lendecke at SerNet.DE
Mon Jan 9 02:30:52 MST 2012

On Mon, Jan 09, 2012 at 04:02:00AM -0500, Catalin Patulea wrote:
> On Mon, Jan 9, 2012 at 3:36 AM, Volker Lendecke
> <Volker.Lendecke at> wrote:
> > What makes the Samba 4 client interface superior to your
> > needs over the Samba 3 client interface? In the past years,
> > we have put a lot of work into the latter, and I would like
> > to know the deficiences to improve it further.
> The main scenario I'm trying to improve on is
> readdir-followed-by-stats. Through GVFS, this occurs when showing a
> File Browser of a share, or a File Open dialog, etc. Because the stats
> are done sequentially, directories with many files are painfully slow,
> even on networks with decent bandwidth, like a Wifi connection.
> Issuing the stats asynchronously would alleviate this problem and
> would better use the bandwidth available on the link.
> I have a proof of concept in smbclient4 that does this. It's a toy
> problem, a 'dir' which also shows streams information for each file
> entry. But async qpathinfo2 against an XP server does seem to work,
> and it does speed things up.
> It seems I neglected to check the latest version of the Samba 3 client
> API - I was under the impression that it did not have an async request
> interface. I see cli_qpathinfo2_send in source3/libsmb/clirap.h. Is
> this part of a supported, stable interface?

That is as much part of the stable interface as the samba4
raw interface is. We try not to change it, but unfortunately
the only interface that we fully promise to support as
stable is the libsmbclient.h one. As Stefan wrote, we are
working towards a support async interface that is common to
both S3 and S4.

BTW, for the readdir-after-stat you can just use an extended
infolevel for the trans2 findfirst/findnext. You don't need
the qpathinfo for *that* problem.


SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen, mailto:kontakt at

More information about the samba-technical mailing list