s4/torture: port SMBv1 RAW-LOCK tests to SMBv2

[tridge at samba.org]

Hi Steven,

 > I did not investigate or fix these errors before committing the tests as
 > I have zero context with the way Samba4 handles SMB2.  The tests do pass
 > against both W2K8 and W2K8R2 servers.

passing against windows in this case may not be the right thing to do :-)

For the "lock reply on tdis" and "lock reply on logoff" tests in
SMB2-LOCK, I think s4 was doing the right thing, and that the
behaviour of windows is a potential data integrity bug.

The test checks that when a lock is pending and a tdis or logoff
happens on the same tree, that the lock returns with
NT_STATUS_OK. Imagine you had a windows app that only did some
critical modifications on file server A once it had a lock on a
central resource on file server B. If a tdis/logoff happens, then you
want to be sure that you give an error response back to the lock call,
otherwise the application might go ahead with the critical change
thinking it has the lock when it fact it doesn't have the lock.

Or, to put it more simply, you should never say a lock call succeeded
when it didn't.

 > While I agree that keeping 'make test' passing 100% clean at all times
 > is a desirable goal, I think it's unwise to make this a pre-requisite to
 > committing new, useful torture tests.

If it is a new test then it might be reasonable to add it to
selftest/knownfail, and send a note to someone who might look at it
for you (or as you suggest below, a bugzilla entry).

For changing existing tests then it is probably worth spending a
little bit of time investigating the difference, as perhaps samba4 got
it right and its a real bug that you want to fix in s3 (like with the
two SMB2-LOCK tests I mentioned above).

 > I'd like to make these tests public as soon as they're correct, but I
 > certainly don't want to hinder your verification as you're trying to get
 > a release together.  I think a good policy, and what I'll do is mark the
 > failing tests as knownfail and then file bugs for them in bugzilla so we
 > can track that the issue exists and remind ourselves to remove them from
 > the knownfail state when the server bugs have been addressed.

yes, that sounds good, although I'd also suggest you spend at least a
few minutes looking to see if it really is a s4 bug or not. Sometimes
it isn't, and it may allow you to find more bugs in the s3 code.

Cheers, Tridge