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.