12:45 p.m.
On Thu, 2012-10-25 at 18:19 +0200, Sebastian Heinlein wrote:
Am Donnerstag, den 25.10.2012, 17:50 +0200 schrieb Patrick Ohly:
> On Thu, 2012-10-25 at 17:30 +0200, Sebastian Heinlein wrote:
> > Am Donnerstag, den 25.10.2012, 15:43 +0200 schrieb Patrick Ohly:
> > > On Thu, 2012-10-25 at 15:28 +0200, Sebastian Heinlein wrote:
> > > > Hello Tino,
> > > >
> > > > I tested the packages and my local CalDav/CardDav sync fails with
Debian
> > > > Wheezy. The original Wheezy packages work fine.
> > > >
> > > > The logfile and the stdout are attached.
> > >
> > > | [WARNING] libecal: Cannot get cal from factory: Timeout was reached
> > > | [ERROR] Error allocating calendar
> > >
> > > That looks very much like a mismatch or problem between libecal and
> > > evolution-data-server. Which versions of these are installed?
> > >
> > > I assume accessing the local calendar data fails the same way?
> > >
> > > syncevolution --print-items @dpool calendar
> >
> > The calendar was empty. I created an event and now it works.
> >
> > But I get another problem: syncevolution complains about missing rights
> > to sync my addressbook.
>
> This is a side effect of the earlier failed sync. Please try
> "--refresh-from-remote/local/slow webdav@dpool addressbook".
>
> Use -remote when the CardDAV side has all your data, -local when the
> local side is up-to-date, -slow if both have changes.
>
I did a "syncevolution --sync slow webdav@dpool". It didn't report any
problems but deleted my whole calendar and the todos on the local side.
The items still exist on the server :/
I'm looking at the logs that you sent me. I see that it is happening on
the local side. However, the log for the target side of that sync is
missing; it must have been pruned to keep the maximum number of session
directories below 10.
I should revise the pruning algorithm :-/ It prunes sessions in which
nothing happens, but it considers both sides separately. In this case,
nothing was changed on the target side, so it was pruned, despite making
fundamental changes on the local side.
Regarding why it happens: I see that the target side did not send any
tasks to the local side. Therefore the local side sends Add commands to
the target side, which replies which fake IDs and later requests that
the server deletes the items it wanted to add. That happens when the
recipient detects matches that the sender failed to find.
The root problem is that the target side did not send its data. But I
cannot see why that happened.
Do you see a chance to reproduce this? Use maxlogdirs=0 in the sync
config and target config to disable pruning.
--
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.
3010
days inactive
3010
days old
syncevolution@synevolution.org
0 comments
1 participants
participants (1)
-
Patrick Ohly