GNOME Bugzilla – Bug 680201
Backup restore doesn't migrate accounts from GConf
Last modified: 2012-11-21 19:01:54 UTC
I was testing a spool bug, which meant restoring from backup of 3.2.3, which I didn't think of, but it removed all my sources folders (in .config and .cache). No big deal, I've a month and a bit old backup of evolution, thus I can always recover, but this time something happened. I removed all sources folders, with source registry being closed. Then I restored from the backup (for some reason I was forced to do that twice). But right now my On This Computer shows no subnodes, neither Inbox, it's just On This Computer with no [+] in the folder tree. My ~/.local/share/evolution/mail/local is not empty, just the opposite. I see on console: > (evolution:11116): camel-local-provider-CRITICAL **: scan_fi: assertion > `path != NULL' failed > > (evolution:11116): camel-local-provider-CRITICAL **: scan_dirs: assertion > `path != NULL' failed > > (evolution:11116): evolution-mail-CRITICAL **: file e-mail-account-store.c: > line 1127 (e_mail_account_store_add_service): should not be reached The last one repeats quite many times, I guess more than twenty times, then repeats the first two again. Any idea what can cause this?
Of course, restarting source registry helped, the On This Computer is populated again. These are the last few messages from backup/restore on console: ** Message: rm -rf /home/mcrha/.config/evolution_old ** Message: rm -rf /home/mcrha/.camel_certs_old ** Message: rm /home/mcrha/.local/share/evolution/.running rm: cannot remove `/home/mcrha/.local/share/evolution/.running': No such file or directory ** Message: gdbus call --session --dest org.gnome.evolution.dataserver.Sources0 --object-path /org/gnome/evolution/dataserver/SourceManager --method org.gnome.evolution.dataserver.SourceManager.Reload
Similar issue reported downstream from 3.5.91: https://bugzilla.redhat.com/show_bug.cgi?id=857756 User restored from old backup and even the restore finished successfully, then he was asked for entering a new account, which he just restored from the backup. It seems to me that the reload should not only reload .source files, but also run migration from GConf, otherwise this will never work. And as these (or similar) migrations are done in factories too, then it'll be better to restart them all (also with alarm-notify process), then just "reload".
The registry service already runs both XDG base directory migration and GConf migration when told to reload.
Created attachment 229588 [details] [review] eds patch for evolution-data-server; OK, I hope I found all the bugs here (two patches). From a comment in the patch: /* It's possible the Reload is called after restore, where the ~/.config/evolution/sources directory can be missing, thus create it, because e_server_side_source_get_user_dir() may have its static variable already set to non-NULL value. */
Created attachment 229590 [details] [review] evo patch for evolution; Two issues here: a) hard-coded source manager server name, as Matthew wrote in the code, it is not ideal, and of course (he wrote too), the bump in version was not propagated into backup-restore, thus I changed this and made the name read from DBus' .service file. Work fine here. b) Speed. Speed is evil. At least for restore. I added multiple waits to ensure the data the code expects is there, not in memory. For instance, the GConf keys are not written to disk immediately, and it happened to me that the source registry process was reading old internal GConf xml files, where restored values were not saved yet. The last sleep is there, because it happened to me that the evolution started with all views totally empty, no sources shown so far, in any view. Everything was OK the next evo start.
Created commit 3e17608 in eds master (3.7.3+) Created commit 5c8be90 in evo master (3.7.3+) Created commit 367be5e in eds gnome-3-6 (3.6.3+) Created commit b41e450 in evo gnome-3-6 (3.6.3+)