GNOME Bugzilla – Bug 324679
evolution cant use 2G+ mbox files
Last modified: 2009-08-19 12:49:23 UTC
Please describe the problem: evolution cant use 2G+ mbox files. this means that if you use pop mail, which evolution stores locally as mbox, you're limited to how many messages you can have. Steps to reproduce: 1. set up a pop account 2. send/receive a whole lot of emails 3. watch evolution give you an error that your mbox file is too large Actual results: evolution gives you an error that your mbox file is too large Expected results: evolution appends the file past the 2G+ limit. it's not a filesystem problem, as i'm using 2.6.13 kernel with xfs Does this happen every time? yes Other information:
Confirming as per comment by fejj on IRC.
This is also a problem on 2.6. Any updates on a patch/fix/anything?
I remember Fejj making a patch for some large-file support. I guess this is fixed.
yea, this is fixed
This isn't fixed for me using Evolution 2.8.0. I still get "Cannot append message to mbox file: /home/foo/.evolution/mail/local/Inbox: File too large" ?
Your system should have large file support (O_LARGEFILE flag) On configure stage this is decided. Check with your distro if Evolution is built with large file support.
I'm using Ubuntu Edgy, which does have large file support. As far as Evolution detecting that during configure...I downloaded the source and ran configure --help, but saw no option to enable or disable large file support. I then ran configure with no options and looked in config.log to see what it had decided upon for large file support, but saw no mention of it. How can I tell if Evolution is setting the correct option for this?
the largefile support is in evolution-data-server package, not evolution itself. to check if your system has it, run ./configure and check the generated config.h, if O_LARGEFILE is defined to 0, then your system does not support it. you can check config.log to see what the error was.
I ran configure with the same options as the distribution used (in debian/rules) and evolution-data-server did indeed say that it *had* large file support. Just to be sure, I removed the one that came with my distro and configured/built/installed one from source, making sure that it had large file support enabled. I still receive this error and cannot use my mailbox.
*** Bug 551413 has been marked as a duplicate of this bug. ***
So are there any issues in turning on large-file support for those distros that haven't yet? I vaguely remember someone saying it breaks backward compatibility in the binary format of the index files (or was it something else), but is that still an issue now with the SQLite databases? I'm getting tired of all the dupes for this...
*** Bug 584042 has been marked as a duplicate of this bug. ***
*** Bug 511552 has been marked as a duplicate of this bug. ***
Splendid, a colleague encountered yesterday the same problem, but got no error message (at least no dialog, but haven't checked xession-errors). The Inbox grew over the 2G limit and no message was shown. We managed to gain access to them by converting the mbox to maildir with mb2md and configuring a fake delivery inbox pointing to the converted inbox. May I suggest Evolution changes the default storage format from mbox to maildir? It supports delivery to maildir, I don't see why it shouldn't support storing the mails got via POP in maildir format. Switching to maildir format would also fix for large inboxes performance issues (when deleting mails), possible corruptions, inconsistencies or old data (sudden power outage), problems when free space is less than the current size of the mbox to be modified. I imagine Evolution is smart enough not to lose mails (since it never lost me mails), but it will probably have stale data in case of sudden stops like power outages. OTOH, if maildir-as-default-storage isn't implemented, and if the mail box gets close the 2G limit*, Evolution could warn the user and advice to filter, move away or remove messages from the troublesome „directory”. * in spite of the large file support option compiled in in distribution packages, it seems there is still a problem with it actually working.
*** This bug has been marked as a duplicate of bug 522433 ***