Re: [Evolution] POP3 mbox performance and auto-expunging?

[Milan Crha <mcrha redhat com>]

On Thu, 2008-08-21 at 22:16 -0430, Patrick O'Callaghan wrote:
> A 32-bit system might give a different result but I don't have one to
> test. In any case, if there is a difference I would assume it to be
> caused by an address-space limitation (or lack of available swap) rather
> than a problem with the filesystem. AFAIK ext3 on 32 and 64-bit versions
> of Linux is the same. Note that procmail and formail process their input
> sequentially, so would not be subject to this kind of problem.

        Hi,
as far as I know, Evolution uses summaries to handle with mbox files
(and with other types too), just to have quicker access to the mails.
With mbox, there are stored offsets in the file to the beginning of the
message. The problem on 32bit system is that the offset is signed int of
32bit size by default, (on 64bit it's 64bit signed int), so it breaks
itself when trying to access mail on the offset greater than 2^31.

It's possible to turn on large file support in compile time, but the
problem is then with existing users, some migration should be done,
because some information is stored only in the summary, not in the mbox
file itself.

Next version of Evolution (2.24) will contain other kind of summaries,
the sqlite, but I do not know how they compute the file offset, if it's
based on the ftell, then the problem persists as long as the large file
support is turned off. I was told, some time back, that the default size
of the offset column in the sql table will be 64bit, regardless of the
actual operating system, so turning the large file support on will not
have any negative impact on existing users. In case this is truth, then
this option can be turned on by default now. (Also the migration code
from old summaries to the db-summary is there too, thus everything is
ready in the development version.)

By the way, there are some plans to move to maildir format for local
folders, but it has some limitations and its bugs (as was told before by
someone else), which requires to extend and fix those bugs in the
maildir provider. There is no way to turn the maildir for local folders,
it's hardcoded to mbox at the moment.

Just my two cents.
        Bye,
        Milan