12:38 a.m.
http://bugs.meego.com/show_bug.cgi?id=11044
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING FOR UPSTREAM
AssignedTo|syncevolution-bugs(a)meego.bu |patrick.ohly(a)intel.com
|gs |
Target Milestone|--- |1.1.1
--- Comment #1 from pohly <patrick.ohly(a)intel.com> 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 <patrick.ohly(a)intel.com>
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 <patrick.ohly(a)intel.com>
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.