http://bugzilla.moblin.org/show_bug.cgi?id=9682 pohly <patrick.ohly(a)intel.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |7214 -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

http://bugzilla.moblin.org/show_bug.cgi?id=9682 --- Comment #2 from pohly <patrick.ohly(a)intel.com&gt; 2010-04-19 08:29:07 PST --- This can be simplified: - clear all items on a server which uses the file backend - slow sync with one item on client A - modify item on client A so that a key element differs (like SUMMARY in task) - slow sync again Expected result: - client and server in sync, either with one item or two Actual result: - server has two items, client one (the unmodified one from the initial sync) The root cause is that the server treats these two items as different when using the file backend, because neither that backend nor the engine know about the significance of the UID property, which happens to be identical here. In the second slow sync, it sends an <Add> command with the item that it had from the initial sync. The client then turns the <Add> into a <Replace> of the item that it just sent to the server, overwriting the local, more recent data with the older copy from the server. The client uses the EDS backend, which detects that the new item from the server has the same UID as a local item, and therefore it *replaces* that item instead of adding it anew. IMHO the correct solution would be for the server to detect that two conflicting items have the same UID. The UID of the item on the server then must be replaced with something which satisfies the iCalendar 2.0 "globally unique" criteria before it is sent to the client in an <Add>. Or the property must be cleared, which will cause the client to create a value. I have no idea how to implement either one or the other, though. Solutions which don't work: - Compare only the UID property. A) we don't know whether the client really provides a stable, globally unique UID and b) we would end up with only one item even when both items were modified and thus should both be preserved. - Don't store UID on the server. We want it there for backup/restore of iCalendar 2.0 clients. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.