Thanks Howard, Sorry, my interpretation of RFC4533 terminology :) . What I read is that the client may select from 2 modes of operation (by providing an initial cookie). The first is described in the section called "initial content poll", the second is called "content update poll". The server may however ignore the request for a content update poll and do an "initial content poll". I was writing about that the client can not reliably determine which mode was selected by the server. But I now see that it does not matter; at both the end of the "initial content poll" /and/ at the end of present phase (that is, without a delete phase) one should delete all unmentioned client content. Indeed. With the addition that this message is used to end both the "initial content poll" as the "content update poll". Still, this interpretation can not be correct. When I run my sync client program against OpenLDAP (2.3.36), and then restart it after the refresh stage with the last received cookie (note: the DIT remains unchanged), the first message is exactly that SyncInfoMessage of refreshPresent with refreshDone set to TRUE. Using our interpretation I should now delete all client content! Since the DIT was not changed this is clearly wrong. (By the way the new server cookie is the same as the initial cookie, but depending on this is tricky; the client should never interpret the cookie.) I am quite confused here. Where is the error in our reasoning? Regards, Erik. -- Erik van Oosten http://2008.rubyenrails.nl/ http://www.day-to-day-stuff.blogspot.com/

Howard Chu wrote: I am talking about a refreshAndPersist operation (otherwise I would not get a syncInfoMessage with refreshDone set to true). Mode refreshOnly is working as expected. You say Sync Done refreshDeletes, that is indeed what you get with refreshOnly. However, with refreshAndPersist you get a single syncInfoMessage of refresh*Present*. Shall I report this as a bug? My interpretation of 'no cookie' in the SyncDone/SyncInfoMessage was to use no initial cookie in the next synchronization. But your interpretation is probably better indeed. Okay thanks, I'll use that assumption. I'll also use the assumption that if the cookie is the same, no changes have occurred. Thanks, Erik. -- Erik van Oosten http://2008.rubyenrails.nl/ http://www.day-to-day-stuff.blogspot.com/

Howard, Thanks for your support and the quick fix! Regards, Erik. PS. I filled a second, much smaller, syncrepl bug under ITS#5211. Howard Chu wrote: -- Erik van Oosten http://2008.rubyenrails.nl/ http://day-to-day-stuff.blogspot.com/

Howard Chu wrote: I am about done and quite happy with the result. I only need to write code to restart aborted syncs and some more code to manage many concurrent syncs in just a few threads. I am afraid I am not allowed to open source this :( (I did ask). The effort was too large (about a week, but that excluded a lot of prior research), and the advantage compared to competitors in our market is just too large. I will however post a tutorial on extending JLDAP so that at least others can get a grasp on how to approach this. I'll post the link here when its done. Great! Regards, Erik. -- Erik van Oosten http://2008.rubyenrails.nl/ http://day-to-day-stuff.blogspot.com/