[RFC] Advice on SMB client python bindings?

Tim Beale timbeale at catalyst.net.nz
Tue Dec 11 00:47:40 UTC 2018


Hi Metze,

OK, I'll take a look. BTW, your pipeline will fail. The knownfail I
added in one of my patches needs updating after the Python3 changeover.
I can fix this up.

Cheers,
Tim

On 11/12/18 12:21 PM, Stefan Metzmacher wrote:
> Am 04.12.18 um 17:44 schrieb Stefan Metzmacher via samba-technical:
>> Hi Tim,
>>
>>> Thanks for the patches Metze. Unfortunately that doesn't help me with
>>> supporting SMBv2 at all. Attached is an example test-case
>>> (smbv2-problem.txt) that tries to run the .unlink() API against a DC
>>> with SMBv1 disabled.
>> Yes, sorry! I looked briefly at cli_unlink() and thought _send/_recv
>> would already do the correct thing and only others like cli_mkdir()
>> had the problem. But it seems I was just dreaming...
>>
>>> Taking a step back, the problem I'm trying to solve is this:
>>>
>>> Finally, I don't really understand why using the async APIs in the
>>> Python bindings is so important. For example, smbclient uses the
>>> synchronous APIs. If someone could explain the rationale behind all
>>> this, it might help. Or to put it another way, why is using the async
>>> APIs more important than delivering software that fixes a real problem
>>> for real Samba users?
>> Yes, removing the dependency to SMB1 should be our first priority.
>>
>> The async stuff is mainly for testing the async protocol behavior,
>> in order to simulate multi threaded applications.
>>
>> Would you be able to work from the attached patchset?
> Here's a bit more that's needed for my dcerpc security context
> multiplexing support.
>
> Can I get your review an this?
>
> Then I'll add BUG references to
> https://bugzilla.samba.org/show_bug.cgi?id=13676
> https://bugzilla.samba.org/show_bug.cgi?id=7113
> https://bugzilla.samba.org/show_bug.cgi?id=11892
> and maybe more.
>
> A pipeline is running here:
> https://gitlab.com/samba-team/devel/samba/pipelines/39644216
>
> Thanks!
> metze
>



More information about the samba-technical mailing list