Add smbstatus test (lock file with smbclient)
slow at samba.org
Wed Mar 13 15:16:13 UTC 2019
> Am 13.03.2019 um 15:53 schrieb Andreas Schneider <asn at samba.org>:
> On Wednesday, March 13, 2019 3:02:25 PM CET Ralph Böhme wrote:
>> Hi Andreas
>> Am 13.03.2019 um 12:08 schrieb Andreas Schneider via samba-technical <samba-
> technical at lists.samba.org>:
>>> I've created a patch for 'smbstatus -L --resolve-uids' to show usernames
>>> instead of UIDs as I have a customer request for it.
>>> However Andrew rejected the patch to go in without a test. I've tried to
>>> implement a test for smbstatus but it doesn't work. My problem is that I'm
>>> not able to create a lock on a file to show up with smbstatus later.
>>> I can:
>>> open <file>
>>> but I can't pass the returned fnum to
>>> lock <fnum> r 0x0 0x1
>> Looks like lock is obly implemented for SMB1. Also, you seem to use a
>> hardcoded fnum value of 0, for SMB2+ I seem to get 1, and for SMB1 it's
>> worse, as you'll get a random number there.
> I just put 0 there to have a number, you need to pass the one you get from
> open which I can't.
You don't need a brl-lock to test smbstatus -L, all you need is an open. Or am I missing something?
> So with SMB2+ it would be more reliable, but we don't have
> Unix extensions yet (*hint*)!
Hm, why do we only support POSIX brl in smbclient? SMB support byte-range-locks out-of the box, no need for UNIX extensions here. Jeremy?
More information about the samba-technical