GNOME Bugzilla – Bug 584624
folders.db files corrupted on sync between 2 machines
Last modified: 2013-09-14 16:52:51 UTC
Steps to reproduce: 1. start evolution after using rsync to sync .evolution trees on 2 similar machines 2. 3. Stack trace: Other information: I use rsync to keep .evolution synced between two machines (both i686's, running slackware 12.2, and garnome, updated to current releases, and git/master versions of evolution, eds, gtkhtml, libsoup, etc.). This has worked reliably for years; When I started evolution yesterday (and today) on either machine, I noticed that all the local mail folders didn't show up. The console is full of messages like: (evolution:30901): camel-WARNING **: something went wrong terribly during db creation (evolution:30901): evolution-mail-WARNING **: Could not setup local store/folder: malformed database schema (16) - near "0": syntax error (evolution:30901): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:30901): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed Exiting evolution and purging all the db's fixes the problem. Not only do I have all my mail (thankfully), but I can start and stop evolution (with evolution --force-shutdown) without problem, at least until the next sync between the machines. Other Information: I had upgraded gtk+ (to 2.17.1) and glib (2.21.1) over the weekend, and rebuilt evo etc.
Let's try to find out what's going wrong. I would like to suggest to do this test: Before the sync run command [1] on both databases, and be sure it results in "ok". Then run sync and when it'll be finished, before you run evolution, also run the command [1] on both of them, to see whether the rsync did its job properly. Thanks. [1] sqlite3 <db> "PRAGMA integrity_check;"
The problem is solved. Basically, the sqlite3 test Milan suggested showed that: 1) the regenerated office desktop folders.db was ok and copied correctly to my portable drive (although I moved the existing .evolution directory away on the portable drive). 2) When I got home, the portable drive's folders.db was still OK (:)) but the one on the hard drive was not (basically the same error). Worse, it had a timestamp that was in the future, which means that the sync would always reinfect the portable drive. Don't understand how the bogus timestamp might have arisen (while evo has crashed there are no system crashes here in a long time). In any event, removing the folders.db file before syncing leads to the problem being solved. I'll close this.