[SyncEvolution] Problem syncing with two profiles

Patrick Ohly patrick.ohly at intel.com
Fri Nov 11 07:37:32 UTC 2016


On Thu, 2016-11-10 at 23:09 +0100, deloptes wrote:
> deloptes wrote:
> 
> > Patrick Ohly wrote:
> > 
> >> Sync with what? Mobile phone?
> >> 
> > 
> > Yes! I use Nokia N9.
> > 
>  
> >> There was a bug that affected some phones such that the sync itself
> >> completed, but the OBEX connection was closed prematurely, causing some
> >> phones to believe that an error occurred. But that should be fixed in
> >> master.
> > 
> > Perhaps I use loglevel=10 ?
> > 
> > regards
> 
> FYI: I tried now without refresh-from-remote. I synced last time in the
> office and now first time at home. It went into slow sync immediately with
> following result. The next sync was normal.

So switching between home and office triggers a slow sync? I wonder
whether the phone sees different deviceIds for the SyncEvolution side in
that case.

There are two settings in SyncEvolution for this. From a config for the
Nokia N97:

# the identifier sent to the remote peer for a server initiated sync.
# if not set, deviceId will be used instead
remoteIdentifier = PC Suite

# The SyncML server gets this string and will use it to keep track of
# changes that still need to be synchronized with this particular
# client; it must be set to something unique (like the pseudo-random
# string created automatically for new configurations) among all clients
# accessing the same server.
# myFUNAMBOL also requires that the string starts with sc-pim-
# deviceId = 

We do server initiated syncs with phones, so "PC Suite" is sent to the
phone in the initial message. If I remember correctly, that had to be
that fixed string, at least with some Nokia phones.

Note that there's no unique deviceId here, which means that different
computers will all look alike to the phone, which then notices a
mismatch of sync anchors when moving between computers and thus forces a
slow sync.

Hrm, there's a nice fat TODO in src/syncevo/SyncContext.cpp about this:

    if (m_serverMode) {
        // TODO: set the device ID for an OBEX server
    } else {
        substTag(xml, "fakedeviceid", getDevID());
    }

I don't remember why that if() check is there, and why
SyncConfig::createPeerTemplate()'s
config->setDevID(string("syncevolution-") + UUID()) is not used to set a
unique deviceId when configuring phones.

Answering that would require some further code archeology and
experimenting; not sure when I will have time for that. Perhaps you can
check?

Here's an example of a sync with a SyncML server:

http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_001_outgoing.xml
<Source><LocURI>syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65</LocURI><LocName>syncevolution at lists.intel.com</LocName></Source>

The server then replies with:
http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_002_incoming.xml
<Target><LocURI>syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65</LocURI><LocName>syncevolution at lists.intel.com</LocName></Target>
<Source><LocURI>http://www.plan44.ch/fsync_nightly</LocURI></Source>

Perhaps that's the reason for the if() check: a HTTP server might
require a different LocURI (?) than an OBEX server, and the code does
not immediately know what it is (depends on the transport).

-- 
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.






More information about the SyncEvolution mailing list