s3: Fix an assert to trigger in close_remove_share_mode
commitd792f59aeb4e74ea14d3c5979addd31b78b1a2d9
authorStefan Metzmacher <metze@samba.org>
Fri, 1 Jun 2012 14:29:51 +0000 (1 16:29 +0200)
committerStefan Metzmacher <metze@samba.org>
Sun, 3 Jun 2012 15:23:28 +0000 (3 17:23 +0200)
tree0247314c86f9dcce7e1fe0541c2f974c167293ad
parentb9e11bd63ee6e1f1aac8d3b8a61ef0a4734cdd98
s3: Fix an assert to trigger in close_remove_share_mode

In case we have a left-over entry in the share mode entry array,
the SMB_ASSERT(got_tokens) is likely to kick in. It happens when
we are about to delete a file with initial delete on close. We don't
have a delete on close token set in the locking.tdb record. We see
the fsp->initial_delete_on_close set, add the delete_on_close token
to lck. Then "delete_file" is being set to true. Then later on we
do the notify_deferred_opens. This walks the list, also checking
for share_mode_stale_pid. We have already deleted our own share
mode entry, share_mode_stale_pid() sees the left-over entry. It not
also deletes that one but also the delete on close token. This leads
to a different view of "delete_file" a.k.a. "got_tokens" further
down in close_remove_share_mode, leading the SMB_ASSERT to fire.

This patch attempts to fix the issue by keeping around our own share
mode entry for almost the whole routine, preventing share_mode_stale_pid()
from removing the delete tokens.

Pair-Programmed-With: Volker Lendecke <vl@samba.org>
source3/smbd/close.c