Hi Patrick, Hi Anssi,
On May 30, 2010, at 21:43 , Patrick Ohly wrote:
I found something in this log that seems to be the real cause behind all this weird
At the places where these questionable deletes are generated, the server also calls
adjustLocalIDforSize() on the localID of these items to create a GUID that does not exceed
• [2010-05-28 17:36:18.384] translated
It gets tempLocalID #9 here. Fine so far, but for the next delete it gets #9 AGAIN for the
next (different) realLocalID:
• [2010-05-28 17:36:18.385] translated
Now TLocalEngineDS::adjustLocalIDforSize() is implemented to simpy prefixing the current
size of the container plus 1 with a #.
The only possible way to make this create the same key multiple times would be that the
STL map container already contains 8 items, and one of the ALREADY keyed "#9".
The only way how *this* can happen is by malfunctioning SaveAdminDate/UpdateMapItem in a
previous session or LoadAdminData/ReadNextMapItem in the current session, such that
somehow map entries get messed up. Messed up map entries can explain the deletes with no
One possible reason for this could be when a plugin does not properly save/load the
"ident" field in MapIDType, or does not allow multiple map entries with the same
localID, but different ident.
Running syncs with <debug><enable option="exotic"/> would log more
details about the map entries saved and retrieved and thus probably reveal what's
Lukas Zeller (luz(a)synthesis.ch)
Synthesis AG, SyncML Solutions & Sustainable Software Concepts