Latest leases patchset - getting there !

[Michael Adam]

On 2014-11-12 at 23:12 -0800, Jeremy Allison wrote:
> 
> v2_epoch2 and v2_epoch3
> 
> I have a problem with these tests. They're interesting to
> work out how the Windows internal implementation works, but
> they are not credible as a correct functionality test
> for code we're trying hard to get into master and v4-2-test.
> 
> As far as I can tell v2_epoch2 creates a file with
> a v2 lease key(R), then opens the file with an identical
> v1 lease key(RH) and checks that the reply is a v2
> lease reply with correct epoch !
> 
> v3_epoch2 does the reverse by creating with a v1
> lease, and then doing a second open with an identical
> v2 lease key on the same connection and checks the
> server replies with a v1 lease response !
> 
> That might be how Windows server works internally if
> there's an existing v2 or v1 lease and the client does
> something silly and sends a different lease type, but
> it's an insane semantic to test.

I don't think this is implementation specific, but these cases
(ignoring the transport) are part of the protocol specification:

- 3.3.5.9.8  Handling the SMB2_CREATE_REQUEST_LEASE Create Context
- 3.3.5.9.11 Handling the SMB2_CREATE_REQUEST_LEASE_V2 Create Context

But: the docs seem to describe a different behaviour:
The cited sections specify that an create with a REQUEST_LEASE
context (v1) will always get a RESPONSE_LEASE context (v1) in the
create response and that a create request with a REQUEST_LEASE_V2
context will always get a response with a RESPONSE_LEASE_V2
context.

If nothing else, the tests show that the docs are wrong and
need to be adapted, bit it is protocol behaviour and not
implementation specific.

> NO CLIENT WILL EVER MIX V1 AND V2 LEASE TYPES ON THE SAME
> TCP CONNECTION.

I think the point is not that these requests come over
the same TCP connection. They could come over separate ones.
We could extend the test to cover that case.

> I say we keep the tests, mark them as knownfail for
> Samba and move on.
> 
> Later, if we have lots of free time, we can make
> our internal implementation match Windows frame
> for frame and have a party :-).
> 
> But not now we're trying to get this code DONE !

This just also a matter of what one considers "done". :-)

We always criticize implementers who do not implement the spec
but only what the usual clients need of it...

Just my 2¢...

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20141113/373eaa8f/attachment.pgp>