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 _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers