Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes

[ralf@OpenLDAP.org]

Am Freitag 21 Mai 2010 05:52:31 schrieb Howard Chu:
> Ralf Haferkamp wrote:
> > A fix is now in syncprov.c r1.312. Would be great if someone could
> > review it if it makes sense. Testing results look good so far.
> 
> Not sure why this makes the difference. After all, mincsn will be set
> to the consumer's cookie, and any writes that occur during the
> refresh phase will naturally have an entryCSN greater than mincsn and
> still be queued.
That doesn't seem to be true for deletes of entries that have an entryCSN 
less than the value from the cookie. What I did to reproduce the problem 
was:

1. load provider with about 100 entries
2. start consumer wait for it to get synced.
3. stop consumer
4. load more entries in to the provider (in my test case about 1000)
5. restart consumer (the consumer will start a ldapsync session with a 
cookie)
6. use ldapdelete to delete in an entry for the initial 100 entries. 
(those that have an entryCSN < csn provide in the cookie). This ldap 
delete as to happened during the refresh part of the ldapsync session 
(when the 1000 new entries are sent)
7. watch it fail

What happens is that when syncprov_op_mod() calls syncprov_matchops() it 
tests the to be deleted entry against the syncrepl filter (which has the 
entryCSN>=cookie filter prepended currently as we are in refresh). That 
test fails because of the older entryCSN value. Because of that the 
syncoperation will not be inserted into the smatches queue of the 
opcookie and the delete will not get synched in the syncprov_op_response 
callback (as the smatches queue is empty).

(As a side note: Modification that happen during the refresh phase will 
get synched as LDAP_SYNC_ADD instead of LDAP_SYNC_MODIFY for the above 
reasons. This doesn't cause any failure AFAICS but seemed wrong as well.)