10:45 p.m.
http://bugs.meego.com/show_bug.cgi?id=11044
Summary: temporary UID mapping
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: major
Priority: High
Component: SyncML
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-syncml-bugs(a)meego.bugs
Estimated Hours: 0.0
This possibly explains random problems when syncing with phones which have a
short maximum ID size. Not entirely sure (no logs of such failures).
------------------------------------------------
From: Patrick Ohly <patrick.ohly(a)intel.com>
To: Lukas Zeller <luz(a)synthesis.ch>
Cc: Synthesis <os-libsynthesis(a)synthesis.ch>
Subject: [os-libsynthesis] temporary UID mapping
Date: Wed, 8 Dec 2010 11:22:22 +0000 (08.12.2010 12:22:22)
Hello!
The Synthesis engine has the feature that its backends are allowed to
use IDs of arbitrary length. The engine will translate into IDs shorter
than the maximum ID size supported by the peer.
TLocalEngineDS::adjustLocalIDforSize() creates these temporary IDs,
using:
fTempGUIDMap.size() + 1
// as list only grows, we have unique tempuids for sure
I'm currently (involuntarily ;-) stress-testing this code by running
SyncEvolution<->SyncEvolution syncs with lots of iCalendar 2.0 items,
which happen to have very long IDs.
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. Is the on-disk dump of
fTempGUIDMap really meant to preserve all temporary IDs in perpetuity? I
don't think so, because that would fill up the disk and there is a
"delete map item" operation.
Unless there is some additional constraint, then the assumption that
"the list only grows" is wrong. I have added a workaround which checks
for ID collisions in TLocalEngineDS::adjustLocalIDforSize(). Is that the
right solution or do I need to search for the reason why the mapping has
gaps?
Also note that I end up with a temporary ID which must have been used
before in an older sync session. Could that be a problem?
--------------------------------------------------------
--
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.