serverid patchset ?

[Jeremy Allison]

On Tue, May 22, 2012 at 04:18:54PM +0200, Stefan (metze) Metzmacher wrote:
> 
> If we still have a delete_token, but no valid share_modes we need to
> delete the file.

So I've been thinking a lot about this, and doing some experiments
on Windows.

If a file handle is open with delete-on-close set and we terminate
the TCP connection Windows deletes the file - this is equivalent
to our SHUTDOWN_CLOSE path.

However in this case for Samba we cannot have a situation where
we have zero share modes but a valid delete-on-close token, as
the server will check the validity of share modes and delete the
file as we shutdown.

The only place where we could get zero valid share modes and
a delete on close token is where the client sets delete on
close and then the *server* crashes (or is terminated without
clean shutdown). This is not a case we can test via experiment
against Windows as it's essentially server dependent whether
we delete the file or not after server crash.

What appears to be happening is that we get the server termination
via the new test that requests the server exit without shutdown,
which creates the case where we have a set of invalid share
modes in the db with a delete on close token but no active
processes on the db entry. This is a pure clean up situaion
IMHO and so we should fix share_mode_stale_pid() to delete
any delete on close tokens (and zero their count) if the
number of valid share modes drops to zero.

I think that what is happening in the "make test" scenario
is that we abort a connection and end up with the share
mode db in this state (a list of share modes with a delete
on close token attached but all processes have exited).

Now when the dev/ino pair is re-opened or re-used by
a subsequent process we find the db in this state and
with the original patchset don't clean this up.

I have a couple of changes on top of the original patchset
that fix this, and I'm currently testing it.

Once I'm confident I'll re-post the entire set for
review.

This was a *REALLY FUN* one to work on, thanks for
all your help on this !

Cheers,

	Jeremy.