ralf@OpenLDAP.org wrote:

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.)

OK, that explanation makes sense. Just wanted to make sure we didn't regress on ITS#4622, which seems to be the last time these filters were tweaked.