http://bugs.meego.com/show_bug.cgi?id=11044
pohly <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |WAITING FOR UPSTREAM AssignedTo|[email protected] |[email protected] |gs | Target Milestone|--- |1.1.1 --- Comment #1 from pohly <[email protected]> 2010-12-13 05:38:44 PST --- I ended up patching libsynthesis to work around this issue. Now waiting for confirmation ("[os-libsynthesis] temporary UID mapping") that these patches work as expected: commit a98cdd53f73efae38352039f1d0b5798fd0aa45c Author: Patrick Ohly <[email protected]> Date: Fri Dec 10 14:50:06 2010 +0100 maximum UID size: avoid redundant tempUID->localUID mappings The storage of map items maps from (local id, ident) to ([remote id], flags) and thus cannot store multiple remote ids for the same local id. fTempGUIDMap ended up having such duplicate entries if: - there was an entry from a previous updating of item on the client - the item was deleted on the server, creating a new temporary id to report deletion to the client Such a fTempGUIDMap cannot be stored and retrieved again without loosing the older temporary mappings, which a) might have been still needed (not sure) and b) violated the assumption that temporary ids have to be sequential. This patch checks for an older mapping the the same local id and reuses that mapping instead of creating a new one. It uses a simple linear search, because that is all that can be done unless a more complex data structure is introduced (which might not be worth the effort). commit 50026da88763db4af4077b7157f014e5472f4bab Author: Patrick Ohly <[email protected]> Date: Wed Dec 8 12:33:58 2010 +0100 temporary IDs: avoid reusing existing ID I see failures where the server assigns the same temporary ID to different items in the same sync. I've added debug logging. It shows that the following happens: 1. fTempGUIDMap is restored from the map file such that it has 105 entries, *but* these are non-contiguous (from #1 to #124). 2. fTempGUIDMap.size() + 1 is #106, which already exists in fTempGUIDMap. 3. Overwriting that entry does not increase fTempGUIDMap.size(). 4. A second item is assigned the same #106 temp ID. I don't know exactly how I arrived at this state and whether it is valid. This patch works around the problem by checking for an ID conflict and iterating until it finds a truely unused ID, instead of assuming that "hash size + 1" yields a new ID. The debug logging is also part of the patch, in case that further analysis is needed. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
