Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory



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]