Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory
- From: Srinivasa Ragavan <sragavan novell com>
- To: Hans Petter Jansson <hpj novell com>
- Cc: opensuse-gnome <opensuse-gnome opensuse org>, Evolution Hackers <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory
- Date: Sat, 20 Sep 2008 09:49:18 +0530
Hello Guys,
On Fri, 2008-09-19 at 22:14 -0500, Hans Petter Jansson wrote:
> [ Adding evolution-hackers to Cc since this contains potentially useful
> feedback and some questions ]
>
> On Fri, 2008-09-19 at 18:06 +0100, Michael Meeks wrote:
> > On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
>
> > > Note 2: If you ran the newer version of Evolution previously, you should
> > > delete the sqlite database it creates before reverting to the old one -
> > > otherwise it will think the sqlite database is an mbox and try to index
> > > it, which will cause errors. Delete ~/.evolution/mail/local/folders.db*.
>
> > That - is really bad. Can we not name our db in some way that this
> > doesn't happen ? is there really no solution here ? if not, why are
> > these databases in a place where older versions get confused & start
> > doing stupid things ? - can we not put them somewhere else ?
>
Michael, Its n't possible to keep it there still not findable by the old
version. AFAICS, { ".msf", ".ev-summary", ".ev-summary-meta",
".ibex.index", ".ibex.index.data", ".cmeta", ".lock" } are the possible
extensions that the old version of Evolution ignores. But these have
definite meanings and possible they exist as locks, metafiles or
old-type-summaries. Naming the new summary that way would probably erase
the real data.
> That's a question for the Evo team, I guess - it looks like it could be
> trivially fixed by moving the folder.db somewhere else, or calling it
> folder.index or folder.ibex.index or whatever Evolution traditionally
> filters out.
>
HPJ, the summary can't be named like this, since, its possible that
something like this already exists. .ibex.index has a traditional
meaning and would be more of abusing it in the newer versions.
> To Evolution's credit, my 500MB folder.db binary blob didn't cause it to
> crash - it showed up as a bogus local mail folder after about 15 minutes
> of disk churn - but it did throw errors whenever it needed to pull data
> for vfolders.
>
But, the old version shouldn't touch the folders.db automatically,
meaning the new summary would be safe, unless the user manually deletes
or adds mails to it.
> Also, it looks like old summary/index files aren't removed - does it
> require both the sqlite database and summaries now? It increases disk
> space consumption quite a bit.
That is left purposefully. Incase you are a user switching across
versions, probably you would have to recreate summaries every time you
do. But first time, we just migrate and don't care later on. So if you
aren't a user of that category, a rm of it manually should suffice.
[probably some more summaries left on the other accounts]
>
> > Switching between versions, should work right ?
>
Michael, AFAICS, it should work fine, we don't touch old summaries
written by old version. If it happens, file a bug (I dont think it
happens ):-) Just that the old version reports you of a new folder
folders.db.
Should we ship a patch for older Evolution versions to ignore
folders.db? May be worth for power users of SLEs and RHEs, who might
still use older version & new version.
-Srini
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]