Re: [Evolution-hackers] Moving from the single mbox file format for the local folders

[Jeffrey Stedfast <fejj novell com>]

On 12/17/2009 05:36 AM, Milan Crha wrote:
> On Wed, 2009-12-16 at 19:56 -0500, Jeffrey Stedfast wrote:
>   
>> Does it really crash? It used to just regenerate the summary files.
>>     
> yes, on out of memory, as it tries to allocate a very large memory block
> due to misreading items.
>   

Ah, okay, I can see that happening. Depending on what is allocating the
memory, it might be possible to switch from g_malloc() to g_try_malloc()
to avoid this problem. However, if it is inside GPtrArray or something,
might not be doable.

>
>   
>>> 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.
>>     
> I do not think the above will work together with defaulting to LARGEFILE
> compile flag, but the other way would, like defaulting to load_int32 for
> older summaries and reading off_t for new.

What you will want to do is always save file offsets as int64 in the new
version, no matter whether LARGEFILE support is enabled or not.

You also want to keep using load_off_t() for the older versions because
that's what the code does now. If you make it use load_int32() it will
break for 64bit systems or any system using LARGEFILE support (e.g.
anywhere off_t is 64bit).

>  I'm wondering whether some
> distro has the largefile support enabled these days, as if so, then the
> decision what to use as an off_t size isn't that easy. Maybe they have,
> or it's enough to compile under 64 bit to have the size changed.
> I didn't try this, I just suppose because of reported issues.
>   

As long as you bump the summary version number, this isn't a problem if
you do something along the lines of the code I posted above.

Keep in mind, the new summary code will have to *always* save offsets as
8 bytes as opposed to sizeof (off_t), but that's ok - that's what you
ultimately want anyway (you want the file format to stay the same no
matter if LARGEFILE is enabled or not).

Actually, the summaries aren't even saved in the binary summary format
anymore, are they? They're in some sqlite db now, right?

Jeff