Add smbstatus test (lock file with smbclient)
jra at samba.org
Fri Mar 15 18:30:57 UTC 2019
On Wed, Mar 13, 2019 at 04:16:13PM +0100, Ralph Böhme wrote:
> > 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?
Nope, you don't need a brl-lock to test --resolve-uids,
just an open is enough.
> > 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?
The 'lock' command was only added for UNIX extensions
hand-crafted testing (I used it to peek inside /proc/locks/
when coding SMB1-UNIX up initially).
Could be generalized for SMB non-posix but to be honest
it isn't really a useful command (but we probably can't
drop it now :-).
More information about the samba-technical