serverid patchset ?

[Stefan (metze) Metzmacher]

Hi,

>>> - Log -----------------------------------------------------------------
>>> commit f5ca3f11e47e48d195616f813b5b2c9e8255c6cd
>>> Author: Volker Lendecke <vl at samba.org>
>>> Date:   Fri May 18 09:10:02 2012 +0200
>>>
>>>     s3: Revert the serverid changes, they need more work
>>
>> Ok, now both you and I have done more work over the weekend on
>> this, and the autobuilds do seem much more stable, may I have your
>> official permission to re-push this patchset ?
>>
>> I really do think (a) it works, and (b) it's a significant
>> improvement on what is currently in master.
>>
>> Please let me know what you think.
> 
> What have you changed exactly?
> 
> Where can I look at the current patchset?
> 
> Where you able to reproduce the DELETE_PENDING problem?

I think we found the problem with DELETE_PENDING.

The code in open_mode_check() looks like this:

        int i;

        if(lck->data->num_share_modes == 0) {
                return NT_STATUS_OK;
        }

        *file_existed = True;

        /* A delete on close prohibits everything */

        if (is_delete_on_close_set(lck, name_hash)) {
                return NT_STATUS_DELETE_PENDING;
        }

Before parse_share_modes() cleaned up stale share mode entries,
as result lck->data->num_share_modes is 0 and we can return NT_STATUS_OK.

Now without the cleanup lck->data->num_share_modes can be > 0,
which can result in NT_STATUS_DELETE_PENDING, as is_delete_on_close_set()
doesn't verify anything.

If we still have a delete_token, but no valid share_modes we need to
delete the file.

But the current code just returns OK and doesn't touch *file_existed,
I think in order to get this patches in it's enough to provide the same
behavior as before.

It's still strange why we trigger this behavior from autobuild,
as all processes should cleanup correctly.

For testing we should add a DEBUG(0,) and print all cleanups of
non-existing processes and see how often an autobuild triggers this
and when.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120522/0ca97eff/attachment.pgp>