serverid patchset ?

[Jeremy Allison]

On Tue, May 22, 2012 at 09:06:20PM +0200, Stefan (metze) Metzmacher wrote:
> 
> I know, but the code from last week didn't have
> https://gitweb.samba.org/?p=samba.git;a=commitdiff;h=d79b46f358d7e6fd942bb0f3da2174455e9b1740
> See
> https://git.samba.org/autobuild.flakey/2012-05-18-0420/samba4.stdout
> 
> So the unclean shutdown seems to happens somewhere...

Sure.

> A server crash means the file should be deleted!
> It's 100% the same as a TCP disconnect, so we should try to remove the
> file on cleanup...

No, I don't think so. A server crash is very different
from a TCP disconnect. We handle the TCP disconnect
gracefully on server shutdown and don't leave the db
in an invalid state.

It's impossible to tell from a cleanup with zero valid
share modes but a valid delete-on-close token if the
actual pathname you're deleting is the correct one at
all. You've lost the context on any of the the opens.

Remember, you could have a file with delete-on-close
set, the server crashes after the file is deleted
but before the share mode is removed. Now you have
an entry in the share mode db indexable by a dev/ino
pair, with no valid share mode entries but still has
a delete-on-close token. Someone then creates a new
file that happens to have the same dev/ino (maybe
a different path, maybe not). If on cleanup you
treat the zero-valid-entries+delete-on-close token
as a valid state and do the delete on cleanup on
that pathname then you stand the risk of removing
the wrong file.

All bets are off after a server crash, that entry
is in an unknown state and the only thing you can
do (IMHO) is clean it out - not take action on it.

It also massively complicates the cleanup code, wheras
right now it's really simple to do the cleanup as "if
zero valid share modes remove the delete-on-close
token" (and I have a patch that sits on top of vl's
patchset that does just that :-).

Jeremy.