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.

Evolution-hackers mailing list

Reply via email to