Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
- From: Jeffrey Stedfast <fejj novell com>
- To: Milan Crha <mcrha redhat com>
- Cc: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
- Date: Wed, 16 Dec 2009 19:56:32 -0500
On 12/16/2009 02:40 PM, Milan Crha wrote:
> On Wed, 2009-12-16 at 11:35 -0500, Jeffrey Stedfast wrote:
>
>> The summary files would have had this problem, but they would have
>> just been regenerated, so not really an issue.
>>
> Hi,
> a) it's similar as moving from 32bit to 64bit architecture or the other
> way; evo crashes for these situations, because the version is fine, but
> it doesn't know whether the previous one was a 32bit or 64bit machine,
> aka whether it should do some "translation" or not. (and doing
> translation is not as that simple for usage of functions which are doing
> sizeof(...); not a problem with db-summary, but still might be with
> indexes and store summaries, I didn't check that.)
>
Does it really crash? It used to just regenerate the summary files.
> b) you cannot just drop it and regenerate, because it holds some
> information for local providers, like labels, tags and such.
>
The point of the version info was so that you could do things like:
if (summary->version < CAMEL_64BIT_SUMMARY_VERSION) {
off_t offset;
camel_file_utils_load_off_t (file, &offset);
info->offset = offset;
} else {
camel_file_utils_load_int64 (file, &info->offset);
}
If you do this, then you don't actually lose any information.
Jeff
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]