Re: [SyncEvolution] one-way-sync not respected
On Mon, 2013-07-22 at 16:03 +0200, Patrick Ohly wrote:
On Mon, 2013-07-22 at 07:06 -0300, Juan Antonio Zuloaga Mellino
wrote:
> I realize I didn't explain myself properly:
>
> Google requires authentication for accessing the caldav api.
>
> On public calendars, any authentication credentials are accepted for
> reading public calendars.
>
> Trying to write on remote without ownership produces the 403 error.
> Reading doesn't produce it. I don't know if that's expected.
>
> Why does syncevolution try to access writing functions, if one-way
> sync was selected?
The log helped. Something is going wrong with change detection: the
remote side is requesting an "Add" of an item which already exists
locally.
The local side then eventually comes to the conclusion that the remote
side has too many items and tries to delete some. It shouldn't do that
and the remote side rejects that without ever trying to write to
Google.
In other words, sync is one-way as intended, it just doesn't quite work
as intended. I'll try to reproduce here.
It worked for me, at least for now:
syncevolution --configure loglevel=3 backend=caldav
database=https://www.google.com/calendar/dav/vi6voh10oa187gg9nvs8pkqt7s@g...
username=xxxx password=yyyy target-config@google-readonly feiertage
# Using local system calendar:
syncevolution --configure database= backend=evolution-calendar
syncURL=local://@google-readonly uri=feiertage peerIsClient=1 google calendar
syncevolution --sync refresh-from-remote google calendar
syncevolution --sync one-way-from-remote google calendar
Are you sure that you were not using local-cache mode? I can't reproduce
it with that mode either, but it would explain a bit better how you
ended up in the situation where the problem occurred.
Either way, please try to figure out how to trigger the problem and
write down all steps.
--
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.