After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 642229 - Loss of Calendars
Loss of Calendars
Status: RESOLVED DUPLICATE of bug 632962
Product: evolution
Classification: Applications
Component: Calendar
2.32.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2011-02-13 14:31 UTC by Johann Glaser
Modified: 2011-03-01 10:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Johann Glaser 2011-02-13 14:31:22 UTC
After the upgrade from 2.30.3 to 2.32.2 the calendar component lost some calendars. They appear in the left list of calendars, even with a check, but are not shown in the day view.

When un-checking and then checking a calendar, at the console the following output is printed:

(evolution:12727): libecal-WARNING **: Cannot get cal from factory: No backend factory for 'file' of 'VEVENT'

(evolution:12727): calendar-modules-CRITICAL **: e_cal_shell_sidebar_add_source: assertion `client != NULL' failed

The calendar files are still there and did not change during the update. Some other calendars still work properly.
Comment 1 Johann Glaser 2011-02-13 14:43:39 UTC
See also http://mail.gnome.org/archives/evolution-list/2011-January/msg00029.html

All my calendars contain Unicode characters, some of these are still shown, some others are lost.
Comment 2 Johann Glaser 2011-02-19 14:01:10 UTC
Further investigations showed that the error messages come from ./evolution-data-server-2.32.2/calendar/libedata-cal/e-data-cal-factory.c and ./evolution-data-server-2.32.2/calendar/libecal/e-cal.c.

gdb -p <pidof e-calendar-factory>

#### Working Calendar #####################################
Breakpoint 1, impl_CalFactory_getCal (object=0x7f7ae80d9a40, invocation=0x7f7ad0009700, 
    source_xml=0x7f7aeab0f4f0 "<?xml version=\"1.0\"?>\n<source uid=\"1084736885.32214.139@hansi\" name=\"Mittagessen\" relative_uri=\"1084736885.32214.139@hansi\" color_spec=\"#ffff97\" uri=\"local:1084736885.32214.139@hansi\"><properties><pro"..., type=1, factory=0x7f7ae80d9060) at e-data-cal-factory.c:324
324	{
(gdb) cont
Continuing.

Breakpoint 3, impl_CalFactory_getCal (object=<value optimized out>, invocation=<value optimized out>, source_xml=<value optimized out>, type=1, factory=0x7f7ae80d9060) at e-data-cal-factory.c:380
380		backend_factory = get_backend_factory (
(gdb) print str_uri
$12 = (gchar *) 0x7f7aea47a980 "local:1084736885.32214.139@hansi"

#### Not Working Calendar #################################

Breakpoint 1, impl_CalFactory_getCal (object=0x7f7ae80d9a40, invocation=0x7f7ae9d6e300, 
    source_xml=0x7f7ad2d0d0e0 "<?xml version=\"1.0\"?>\n<source uid=\"1096463463.13797.0@hansi\" name=\"Uni - Psychologie\" uri=\"file:///home/hansi/.evolution/calendar/local/1096463463.13797.0@hansi\" relative_uri=\"1096463463.13797.0@hansi"..., type=1, factory=0x7f7ae80d9060) at e-data-cal-factory.c:324
324	{
(gdb) cont
Continuing.

Breakpoint 3, impl_CalFactory_getCal (object=<value optimized out>, invocation=<value optimized out>, source_xml=<value optimized out>, type=1, factory=0x7f7ae80d9060) at e-data-cal-factory.c:380
380		backend_factory = get_backend_factory (
(gdb) print str_uri
$13 = (gchar *) 0x7f7ad2d01730 "file:///home/hansi/.evolution/calendar/local/1096463463.13797.0@hansi"

############################################################
Difference:
  Working: str_uri = "local:1084736885.32214.139@hansi"
  Problem: str_uri = "file:///home/hansi/.evolution/calendar/local/1096463463.13797.0@hansi"

Now lets search where the difference comes from.

gdb -p $(pidof evolution)

#### Working Calendar #####################################
e_cal_new was not called for working calendars when clicking the check-box in the cal_shell_sidebar.

#### Not Working Calendar #################################
Breakpoint 1, e_cal_new (source=0x7fe1fd6f9a60, type=E_CAL_SOURCE_TYPE_EVENT) at e-cal.c:857
857	e-cal.c: Datei oder Verzeichnis nicht gefunden.
	in e-cal.c
(gdb) print *source->priv
$3 = {group = 0x7fe1fd6f6cc0, uid = 0x7fe1fd9d6470 "1095405156.6801.0@hansi", name = 0x7fe1fd9d6c50 "Personal - Neu", relative_uri = 0x7fe1fd9d6a80 "1095405156.6801.0@hansi", absolute_uri = 0x7fe1fd9d6aa0 "file:///home/hansi/.evolution/calendar/local/1095405156.6801.0@hansi", readonly = 0, 
  color_spec = 0x7fe1fd9d6af0 "#f0a3f0a3f030", properties = 0x7fe1fd6f41e0}
(gdb) cont
Continuing.

Breakpoint 2, e_cal_new (source=<value optimized out>, type=E_CAL_SOURCE_TYPE_EVENT) at e-cal.c:883
883	in e-cal.c
(gdb) print xml
$4 = (gchar *) 0x7fe1fe796080 "<?xml version=\"1.0\"?>\n<source uid=\"1095405156.6801.0@hansi\" name=\"Personal - Neu\" uri=\"file:///home/hansi/.evolution/calendar/local/1095405156.6801.0@hansi\" relative_uri=\"1095405156.6801.0@hansi\" colo"...
(gdb) cont

############################################################

Again we see the full file path in the "uri" attribute.

I recall that during installing Evolution 2.32.2 all evolution files were moved from ~/.evolution/... to ~/.local/share/evolution/...

It seems that for some of the calendars the place where to find the calendar.ics file was not adopted.

Looking into the gconf value for /apps/evolution/calendar/sources shows that some of these values contain an "uri" attribute with the full (but outdated) path, and some only contain a "relative_uri" attribute.
Comment 3 Johann Glaser 2011-02-19 14:20:02 UTC
After manually editing the GConf key /apps/evolution/calendar/sources and removing the "uri" attributes (while keeping the "relative_uri" attributes, which where readily available for every calendar), now all calendars work again.

-> Solution: Please check where these attributes are generated and eventually remove the old "uri" attributes when updating from an older version. It seems they were introduced in some former version of evolution (and therefore included in every <source> entry) and removed again after some time.
Comment 4 Milan Crha 2011-03-01 10:26:55 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 632962 ***