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
less than the value from the cookie. What I did to reproduce the problem
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
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.)