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

[Jeffrey Stedfast <fejj novell com>]

Matthew Barnes wrote:
> On Wed, 2009-12-16 at 09:56 -0500, Jeffrey Stedfast wrote:
>   
>> This just means the proper LARGEFILE flags are not being used at
>> compile time. Either EDS's configure isn't doing proper checks or else
>> Evolution itself isn't doing proper checks and there is some sort of clash.
>>
>> An easy way to fix this is to do what I did with GMime, which is to
>> simply make all public stream APIs that use off_t use goffset instead
>> (I'm sure Matthew will want to do this anyway). Then the problem is
>> much simpler to solve - just make sure that Camel uses the proper CFLAGS
>> for LARGEFILE support (which you can steal from GMime's configure
>> scripts).
>>     
>
> IIRC, the issue is LARGEFILE support is still disabled by default, and
>   

Ah. I'd still suggest switching over to goffset rather than using off_t
in the public API (and for internal state on indexes and wherever else).

> there was concern that simply turning it on would somehow break existing
> installs.  I'm fuzzy on the details, but vaguely recall it being about a
> field size in some binary file being dependent on sizeof(off_t), which
> would change with LARGEFILE support enabled and thus break the binary
> format.
>   

The summary files would have had this problem, but they would have just
been regenerated, so not really an issue.

> Unfortunately I don't remember which file that was an issue in.  It may
> have already been addressed by the move to a summary database, or I may
> just be propagating false rumors.
>   

There may have been other files, but the summary files would definitely
have been affected (tho it would not have been problematic).

Jeff