Messaging patches

[Jeremy Allison]

On Tue, Apr 29, 2014 at 04:41:19PM -0700, Jeremy Allison wrote:
> 
> Of course we shouldn't end up hitting
> an assert when the test tries to tear
> down the test directory paths (which
> is what is happening) but that's the
> root cause of the test fail.

Aha ! And here is the cause of the
assert when the test tries to tear
down the test directory paths..

Wonderful code Volker, you've found
an amazingly long standing bug in
the SMB1 code :-).

The teardown code does:

SMBunlink("test_dir\\*"),
and as one of the files
within test_dir is open,
we should return with a
sharing violation.

However, we have a *really*
old bug inside the wildcard
unlink code, where if do_unlink()
fails whilst deleting a file
when traversing the wildcard
match, we just do "continue"
instead of erroring out
to the caller. This is fatal
in the case of deferring a
sharing violation as it
causes a dbwatch record to
be left around with no
associated SMB1 request.

When the dbwatch timeout
fires, it causes the assert
which for developer mode is
an smb_panic, as we can't
requeue the request as
we already replied to
it...

Here's the fix (attached)
for the record. With this
patch applied on top of the
messaging changes we fail the
samba3.raw.mux test, but without
causing a panic.

So now I'll work out how to cause
the messaging processing to be
re-ordered to match the way the
test code expects (and probably
Windows returns) and then re-post
the entire thing for review.

Cheers,

Jeremy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-smbd-Fix-wildcard-unlink-to-fail-if-we-get-an-err.patch
Type: text/x-diff
Size: 961 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140429/761ce15b/attachment.patch>