Am Freitag 21 Mai 2010 05:52:31 schrieb Howard Chu: 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.)