On Wed, 2013-01-23 at 00:23 +0100, Christof Schulze wrote:
> Hello world,
>
> this is my first post to this list. Recently I set up funambol and
> syncevolution with caldav/carddav on my little arm box. The first sync
> worked, however since then upon running syncevolution leads to aborted
> syncs and the attached log.
>
> From reading the logfile it seems that syncevolution decides that it
> is better to abort but I cannot see the reason for that.
That should also have been the error message on stdout:
Doing a slow synchronization may lead to duplicated
items or lost data when the server merges items incorrectly. Choosing
a different synchronization mode may be the better alternative.
Restart synchronization of affected source(s) with one of the
following sync modes to recover from this problem:
slow, refresh-from-server, refresh-from-client
Analyzing the current state:
syncevolution --status funambol addressbook
Running with one of the three modes:
syncevolution --sync [slow|refresh-from-server|refresh-from-client]
funambol
addressbook
So to fix it temporarily, do a refresh sync as suggested. Note that
"from-client" will take the data from the WebDAV side.
The main question is why the slow sync was necessary.
In this case, the Funambol server decides to do a slow sync:
[2013-01-22 21:01:12.301] Alerted (code=201) for two-way Slow
Sync
It's impossible to say why it does that. One would have to check the
client and server side logs of the previous sync to figure out whether
it really finished cleanly on both sides.
> Now I do not see a spot where the investigation should be started:
> This might be an issue with the data itself, syncevolution, funambol
> or even a performance issue since syncevolution, funambol and the
> webdav (owncloud) are running on the same hardware.
May I ask what you need Funambol for? Perhaps SyncEvolution could do it?
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
