4:55 p.m.
http://bugs.meego.com/show_bug.cgi?id=10265
Summary: Sync must be executed twice to really transfer
calendar events
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Handset
Architecture: ARM
Status: NEW
Severity: normal
Priority: Medium
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: meego(a)misc.lka.org.lu
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
BUILD IMAGE(X.X.XX.X.XXXXXXXX.X - (e.g.:
meego-netbook-ia32-1.0.90.0.20100831.1)):
HARDWARE MODEL (on what HW this bug is uncovered):
Nokia N900
BUG DETAILED DESCRIPTIONS
===========================================================
I'm using syncevolution to keep my caldav calendar and my Nokia N900 calendar
in sync. On the PC (caldav) I've got syncevolution 1.1 running as http server,
whereas on the Nokia I have syncevolution 1.0 (no more recent image available)
running as http client.
I've noticed that it always takes two syncs to propagate modifications from
caldav to the N900. The first sync doesn't perform any modifications, but the
second does all right. Workaround is to just call it twice from my script, but
of course, this also takes twice as long
Clocks of both machines are synchronized within a second (... should that even
matter?)
EXACT STEPS LEADING TO PROBLEM:
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
===========================================================
1. Add a new event in the caldav calendar (using thunderbird for instance)
2. Do a sync, sync says 0 modifications done
3. Consult N900 calendar: event not there
4. Do another sync, sync says 1 modification done
5. Consult N900 calendar: event is not present.
EXPECTED OUTCOME:
===================
Event should be visible after first sync
ACTUAL OUTCOME:
===================
Even not visible after first sync. Only appears after another sync
USER IMPACT:
===================
Slower sync due to the need to do it twice. If user unaware of this, could lead
to scheduling conflicts and/or missed meetings.
REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
=====================================
always
EXTRA SOFTWARE INSTALLED:
============================
OTHER COMMENTS:
===================
- Didn't seem to occur with 0.9 version on the N900 that I had earlier.
- For good measure, I quit thunderbird before doing the sync, just to make sure
that it had actually pushed the events to caldav.
- I also made sure to wait a minute between adding the events and doing the
sync, in order to really exclude any clock difference issues.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
5:12 p.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #1 from alainlux <meego(a)misc.lka.org.lu> 2010-11-20 14:12:16 PST ---
Created an attachment (id=3578)
--> (http://bugs.meego.com/attachment.cgi?id=3578)
Log of first (no-op) sync
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
5:16 p.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #2 from alainlux <meego(a)misc.lka.org.lu> 2010-11-20 14:16:12 PST ---
Created an attachment (id=3579)
--> (http://bugs.meego.com/attachment.cgi?id=3579)
Log of second (successful) sync
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
5:54 p.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #3 from alainlux <meego(a)misc.lka.org.lu> 2010-11-20 14:54:52 PST ---
The weird thing is that when sync runs the second time, it wipes the
~/.cache/syncevolution directory of the first run. However, the next run (after
another change) will not wipe the directory of the second run.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
6:49 p.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #4 from alainlux <meego(a)misc.lka.org.lu> 2010-11-20 15:49:23 PST ---
Created an attachment (id=3580)
--> (http://bugs.meego.com/attachment.cgi?id=3580)
Syncevolution log on server (PC) during first (no-op) sync
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
6:53 p.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #5 from alainlux <meego(a)misc.lka.org.lu> 2010-11-20 15:53:44 PST ---
Created an attachment (id=3581)
--> (http://bugs.meego.com/attachment.cgi?id=3581)
stdout of syncevo-dbus-server on server (PC), first run
This is interesting. Near the end, it shows that it did already pick up the
change... also, in the summary, it noticed that the number of items went from
158 to 159... but still didn't do any modifications, neither locally, nor
remotely...
Weird...
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8:37 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |patrick.ohly(a)intel.com
--- Comment #6 from pohly <patrick.ohly(a)intel.com> 2010-11-21 05:37:21 PST ---
(In reply to comment #0)
BUG DETAILED DESCRIPTIONS
===========================================================
I'm using syncevolution to keep my caldav calendar and my Nokia N900 calendar
in sync. On the PC (caldav) I've got syncevolution 1.1 running as http server,
whereas on the Nokia I have syncevolution 1.0 (no more recent image available)
running as http client.
How does SyncEvolution access the calendar data in your CalDAV server?
(In reply to comment #3)
The weird thing is that when sync runs the second time, it wipes the
~/.cache/syncevolution directory of the first run. However, the next run (after
another change) will not wipe the directory of the second run.
This is probably the "smart" eviction policy for old session directories what
you see here. It tries to keep the number of session directories below the
configured number by deleting sessions in which nothing happened (no changes,
no errors) first. You can turn this off by setting maxlogdirs=0.
(In reply to comment #5)
Created an attachment (id=3581)
-->
(http://bugs.meego.com/attachment.cgi?id=3581) [details]
stdout of syncevo-dbus-server on server (PC), first run
This is interesting. Near the end, it shows that it did already pick up the
change... also, in the summary, it noticed that the number of items went from
158 to 159... but still didn't do any modifications, neither locally, nor
remotely...
Hmm, this output says that one item was created on the PC. Is that the item
that you created manually in order to sync it to the N900?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
11:43 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #7 from alainlux <meego(a)misc.lka.org.lu> 2010-11-21 08:43:35 PST ---
Created an attachment (id=3582)
--> (http://bugs.meego.com/attachment.cgi?id=3582)
my ~/.config/syncevolution/default/sources/calendar/config.ini
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
11:45 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #8 from alainlux <meego(a)misc.lka.org.lu> 2010-11-21 08:45:27 PST ---
(In reply to comment #6)
How does SyncEvolution access the calendar data in your CalDAV
server?
See attached .config/syncevolution/default/sources/calendar/config.ini
(In reply to comment #3)
> The weird thing is that when sync runs the second time, it wipes the
> ~/.cache/syncevolution directory of the first run. However, the next run (after
> another change) will not wipe the directory of the second run.
This is probably the "smart" eviction policy for old session directories what
you see here. It tries to keep the number of session directories below the
configured number by deleting sessions in which nothing happened (no changes,
no errors) first. You can turn this off by setting maxlogdirs=0.
Good, makes sense
(In reply to comment #5)
> Created an attachment (id=3581)
-->
(http://bugs.meego.com/attachment.cgi?id=3581) [details] [details]
> stdout of syncevo-dbus-server on server (PC), first run
>
> This is interesting. Near the end, it shows that it did already pick up the
> change... also, in the summary, it noticed that the number of items went from
> 158 to 159... but still didn't do any modifications, neither locally, nor
> remotely...
Hmm, this output says that one item was created on the PC. Is that the item
that you created manually in order to sync it to the N900?
Yes, that was the item that I created on the PC in order to sync it to the
N900. So it did pick it up, but didn't mention its existence to the N900...
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
4:03 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #9 from pohly <patrick.ohly(a)intel.com> 2010-11-22 01:03:29 PST ---
(In reply to comment #8)
> Hmm, this output says that one item was created on the PC. Is
that the item
> that you created manually in order to sync it to the N900?
Yes, that was the item that I created on the PC in order to sync it to the
N900. So it did pick it up, but didn't mention its existence to the N900...
That doesn't compute for me. If it was already on the PC, why is it shown as
being added locally (= on the PC) *after* a sync? Really strange.
Can you walk me through the exact sequence of steps that you do
(including things like "added event XYZ") and cross-reference that with the
stdout of syncevo-dbus-server and its HTML log files?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
5:22 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #10 from alainlux <meego(a)misc.lka.org.lu> 2010-11-22 02:22:25 PST ---
(In reply to comment #9)
(In reply to comment #8)
> > Hmm, this output says that one item was created on the PC. Is that the item
> > that you created manually in order to sync it to the N900?
>
> Yes, that was the item that I created on the PC in order to sync it to the
> N900. So it did pick it up, but didn't mention its existence to the N900...
That doesn't compute for me. If it was already on the PC, why is it shown as
being added locally (= on the PC) *after* a sync? Really strange.
Indeed, it seems strange.
Can you walk me through the exact sequence of steps that you do
(including things like "added event XYZ") and cross-reference that with the
stdout of syncevo-dbus-server and its HTML log files?
Yes, I've added the event on the PC before starting the sync.
I think I've already posted all relevant HTML log files, including the one on
the PC after first sync (see
http://bugs.meego.com/show_bug.cgi?id=10265#attach_3580).
The two client html files are from an earlier session, but the server html file
is from the same session as the stdout of syncevo-dbus-server.
If you need any additional log file, which would it be?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
6:29 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #11 from pohly <patrick.ohly(a)intel.com> 2010-11-22 03:29:56 PST ---
(In reply to comment #10)
I think I've already posted all relevant HTML log files,
including the one on
the PC after first sync (see
http://bugs.meego.com/show_bug.cgi?id=10265#attach_3580).
The two client html files are from an earlier session, but the server html file
is from the same session as the stdout of syncevo-dbus-server.
If you need any additional log file, which would it be?
The logs on the server side would be more interesting than the logs from the
client side.
But before we go there, let's try to simplify the testing by focusing on the
core aspect which fails here: change detection on the server side. This can be
tested on the server side with "syncevolution --status <client config name>
calendar", without running a sync.
As soon as you add a new event in CalDAV, the command should show a) one item
added in the statistics table and b) the new item data in the diff.
I have a theory: adding the event does not show up immediately via libecal,
which is what SyncEvolution is using. Sometime later, EDS notices and the event
appears. In the example logs, that happened to be between starting and
completing the first sync run.
Does that sound plausible?
If that is the explanation, then I see only one solution: write a native CalDAV
backend instead of relying on the EDS bridge. There is no call which tells
libecal to refresh the data immediately, so there will always be this delay.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
7:11 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #12 from alainlux <meego(a)misc.lka.org.lu> 2010-11-22 04:11:50 PST ---
(In reply to comment #11)
The logs on the server side would be more interesting than the logs
from the
client side.
Yes, that's what I figured...
But before we go there, let's try to simplify the testing by
focusing on the
core aspect which fails here: change detection on the server side. This can be
tested on the server side with "syncevolution --status <client config name>
calendar", without running a sync.
Indeed, this simplifies a lot.
Indeed, the first run after change says:
syncevolution --status n900 calendar
[INFO] addressbook:
inactive
[INFO] todo: inactive
[INFO] memo: inactive
[INFO] Local item changes:
+---------------------------------------------|-----------------------+
| Source | NEW | MOD | DEL |TOTAL|
+---------------------------------------------+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 159 |
+---------------------------------------------+-----+-----+-----+-----+
| start Mon Nov 22 12:45:18 2010, duration 0:00min |
+---------------------------------------------+-----+-----+-----+-----+
Local data changes to be applied remotely during synchronization:
*** calendar ***
no changes
... and the next one says:
[INFO] addressbook: inactive
[INFO] todo: inactive
[INFO] memo: inactive
[INFO] Local item changes:
+---------------------------------------------|-----------------------+
| Source | NEW | MOD | DEL |TOTAL|
+---------------------------------------------+-----+-----+-----+-----+
| calendar | 1 | 0 | 0 | 160 |
+---------------------------------------------+-----+-----+-----+-----+
| start Mon Nov 22 12:45:27 2010, duration 0:00min |
+---------------------------------------------+-----+-----+-----+-----+
Local data changes to be applied remotely during synchronization:
*** calendar ***
after last sync | current data
removed since last sync <
added since last sync
-------------------------------------------------------------------------------
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:zozo
DTEND;TZID=Europe/Paris:20101123T14
0000
DTSTART;TZID=Europe/Paris:20101123T
130000
UID:e0d466e6-b1ec-49fc-bea9-7d94ab6
ae71e
X-EVOLUTION-CALDAV-ETAG:"347697bf1a
f83454521ed8f27c82f0a3"
X-EVOLUTION-CALDAV-HREF:/caldav/cal
dav.php/alain/home/e0d466e6-b1ec-49
fc-bea9-7d94ab6ae71e.ics
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Paris
X-LIC-LOCATION:Europe/Paris
BEGIN:DAYLIGHT
DTSTART:19700328T020000
RRULE:BYDAY=-1SU;BYMONTH=3;FREQ=Y
EARLY
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19701031T030000
RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=
YEARLY
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
END:VCALENDAR
-------------------------------------------------------------------------------
As soon as you add a new event in CalDAV, the command should show a) one item
added in the statistics table and b) the new item data in the diff.
Only happens after I run syncevolution --status the second time after the
change.
I have a theory: adding the event does not show up immediately via
libecal,
which is what SyncEvolution is using. Sometime later, EDS notices and the event
appears. In the example logs, that happened to be between starting and
completing the first sync run.
Does that sound plausible?
Hmmm, not really... It doesn't seem to be timing dependant... even waiting
several minutes before the first syncevolution still keeps the same behavior...
If that is the explanation, then I see only one solution: write a native CalDAV
backend instead of relying on the EDS bridge. There is no call which tells
libecal to refresh the data immediately, so there will always be this delay.
Indeed, this is what seems to be happening: syncevolution connects to Evolution
Data Server, which only seems to poll caldav _after_ the connection (or at
least _after_ feeding its state to syncevolution).
So, a workaround would be to run syncevolution --status first (on PC), and only
then run the syncevolution client from the mobile.
Syncevolution seems to communicate with EDS using DBUS. Maybe there is one DBUS
command which causes EDS to "refresh" itself from caldav which is being sent
too late? Is there a "tcpdump"-like tool for DBUS, so that I could find out
what happens?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
7:44 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #13 from pohly <patrick.ohly(a)intel.com> 2010-11-22 04:44:25 PST ---
(In reply to comment #12)
Indeed, this is what seems to be happening: syncevolution connects to
Evolution
Data Server, which only seems to poll caldav _after_ the connection (or at
least _after_ feeding its state to syncevolution).
Strange, but given that timing doesn't seem to matter, this looks plausible.
So, a workaround would be to run syncevolution --status first (on
PC), and only
then run the syncevolution client from the mobile.
Syncevolution seems to communicate with EDS using DBUS. Maybe there is one DBUS
command which causes EDS to "refresh" itself from caldav which is being sent
too late? Is there a "tcpdump"-like tool for DBUS, so that I could find out
what happens?
There is dbus-monitor.
I have no idea what could be triggering it via libecal, though. Perhaps a
simple libecal open/close would be enough? Do you think you can extract the
relevant calls from either libecal example code (Google search) or the
EvolutionCalendarSource.cpp to try this out?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
7:45 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #14 from pohly <patrick.ohly(a)intel.com> 2010-11-22 04:45:15 PST ---
One additional thought: does the e-calendar-factory process perhaps restart
between the first and second sync?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
9:16 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #15 from alainlux <meego(a)misc.lka.org.lu> 2010-11-22 06:15:59 PST ---
(In reply to comment #13)
There is dbus-monitor.
Good... now I must only find out what to look for in its copious output...
I have no idea what could be triggering it via libecal, though. Perhaps a
simple libecal open/close would be enough?
Do you maybe have a small code snippet to do that?
Do you think you can extract the
relevant calls from either libecal example code (Google search) or the
EvolutionCalendarSource.cpp to try this out?
hmmm, not really, I'm afraid...
I naively tried inserting an extra open call, but then, all I got was:
[ERROR] calendar: opening calendar: file e-cal.c: line 1647: assertion `ecal !=
NULL' failed
Maybe because I was missing a close, but then all
EvolutionCalendarSource::close did was just set m_calendar to NULL... Weird...
When I removed this call again, I still kept getting this, I don't
understand... Makefile bugs?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
9:18 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #16 from alainlux <meego(a)misc.lka.org.lu> 2010-11-22 06:18:13 PST ---
(In reply to comment #14)
One additional thought: does the e-calendar-factory process perhaps
restart
between the first and second sync?
I didn't ever see this process... so either I don't have it, or it's too
shortlived:
ps auxww | fgrep e-calendar-factory | grep -v grep
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
9:34 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #17 from alainlux <meego(a)misc.lka.org.lu> 2010-11-22 06:34:34 PST ---
(In reply to comment #15)
> Do you think you can extract the
> relevant calls from either libecal example code (Google search) or the
> EvolutionCalendarSource.cpp to try this out?
hmmm, not really, I'm afraid...
I naively tried inserting an extra open call, but then, all I got was:
[ERROR] calendar: opening calendar: file e-cal.c: line 1647: assertion `ecal !=
NULL' failed
Maybe because I was missing a close, but then all
EvolutionCalendarSource::close did was just set m_calendar to NULL... Weird...
When I removed this call again, I still kept getting this, I don't
understand... Makefile bugs?
Seems to have been due to a syncevo-dbus-server that I still accidentally had
left running...
After fixing this, the error went away... but then I noticed that apparently
EvolutionCalendarSource::open() is not even being called, if after a
"successful" synchronization.
Weird...
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
6:55 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #18 from pohly <patrick.ohly(a)intel.com> 2010-12-15 03:55:20 PST ---
(In reply to comment #15)
> Do you think you can extract the
> relevant calls from either libecal example code (Google search) or the
> EvolutionCalendarSource.cpp to try this out?
hmmm, not really, I'm afraid...
I naively tried inserting an extra open call, but then, all I got was:
[ERROR] calendar: opening calendar: file e-cal.c: line 1647: assertion `ecal !=
NULL' failed
Yes, opening a calendar instance twice doesn't work.
Maybe because I was missing a close, but then all
EvolutionCalendarSource::close did was just set m_calendar to NULL... Weird...
m_calendar is a smart pointer, so this implicitly destroys the instance it
owns.
I've had some time to look into this and was able to reproduce the problem.
Putting a loop around the code in EvolutionCalendarSource::open() and thus
opening the CalDAV calendar twice does indeed solve the issue.
Workaround will be in SyncEvolution 1.1.1:
commit 7110d70033c06804ae24b421c4f190dc40254b5f
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Dec 15 12:48:34 2010 +0100
Evolution Calendar: work around delayed update in EDS CalDAV backend (BMC
#10265)
Running a sync with EDS CalDAV backend as storage to be synchronized
ignored changes made before the sync. Running the sync again then found
the changes.
It seems that the EDS CalDAV backend triggers a refresh from the
CalDAV server after the client is done, instead of doing that in
e_cal_open().
As a workaround, this patch destroys the newly opened calendar
instance and opens it again. This is done for *all* backends, because
it is cheap for local storage and other remote storage backends might
have the same issue.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
9:06 a.m.
New subject: [MeeGo Projects - Bug 10265] Sync must be executed twice to really transfer calendar events
http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #19 from alainlux <meego(a)misc.lka.org.lu> 2010-12-22 06:06:41 PST ---
Just downloaded 1.1.0.99.1, this works great, thanks!
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
3721
days inactive
3753
days old
syncevolution-issues@syncevolution.org
19 comments
1 participants
participants (1)
-
bugzilla＠meego.com