[SyncEvolution] syncevolution debug help needed

[Patrick Ohly]

On Thu, 2016-07-28 at 19:22 +0200, deloptes wrote:
> Hi,
> from time to time I'm getting in following situation.
> Do you have some hint how I can understand what is wrong here. It works
> fine, but at once I start getting those messages.
>
>  The following output was
> created with SYNCEVOLUTION_DEBUG=3 syncevolution nokia_N9 calendar+todo 

The only unusual message that I noticed is:

> [2016-07-28 18:49:04.473] to-be-added item already exists -> trying replace
> (=conflict resolved by client winning)
> [2016-07-28 18:49:04.473] TCustomImplDS::implProcessItem 0x27e1620 starting,
> SyncOp=replace, RemoteID='496', LocalID=''
> [2016-07-28 18:49:04.473] Executing Script 'beforewritescript'
> [2016-07-28 18:49:04.473] todo: updating "Juli call ptotesi gel"
> [2016-07-28 18:49:04.473] todo: Item delete: (
> 00287b7f-207e-476b-96ad-6d0758d563e1 )
> [2016-07-28 18:49:04.764] todo: Item saved: (
> 00287b7f-207e-476b-96ad-6d0758d563e1 )
> [2016-07-28 18:49:04.764] todo: Item (
> 00287b7f-207e-476b-96ad-6d0758d563e1 : 20160704T075430Z ) done.
> [2016-07-28 18:49:04.764] todo: aID=(00287b7f-207e-476b-96ad-6d0758d563e1,)
> res=208
> [2016-07-28 18:49:04.764] - Operation replace failed with SyncML status=208

I'm not entirely sure why it is marked as "failed" - does that really
break syncing?

DB_DataReplaced = 208 = ITEM_REPLACED in SyncEvolution.

I'm not exactly sure where the "Item delete" and "Item saved" messages
come from. Is that perhaps from your backend?

The underlying problem here is that calendar items are supposed to be
unique, based on their UID. That is a semantic that needs to be enforced
in calendar applications. However, some clients (in particular older,
vCalendar 1.0 based phones) do not support the same semantic. What could
happen is that (for whatever reason - that's often what needs to be
investigated) a phone asks to *add* an item with a UID that already is
in use by an existing item. In that case, the existing item needs to be
updated.

>From SyncSource.h:


    /**
     * When a backend is asked to add an item and recognizes
     * that the item matches an already existing item, it may
     * replace that item instead of creating a duplicate. In this
     * case it must return ITEM_REPLACED and set the luid/revision
     * of that updated item.
     *
     * This can happen when such an item was added concurrently to
     * the running sync or, more likely, was reported as new by
     * the backend and the engine failed to find the match because
     * it doesn't know about some special semantic, like iCalendar
     * 2.0 UID).
     *
     * Note that depending on the age of the items, the older data
     * will replace the more recent one when always using item
     * replacement.
     */
    ITEM_REPLACED,

There are other ways to handle this, in particular see ITEM_NEEDS_MERGE
in SyncSource.h.

Beware that I will be away from email for the next two weeks.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.