Re: mbox file size limitations?
David B Funk <[email protected]> Tue, 17 Jul 2018 13:56:57 -0500 (CDT)
| Newsgroups | gmane.mail.imap.uw.c-client |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 17 Jul 2018, Dan Lukes wrote: > GLEN HERRMANNSFELDT wrote on 17. 7. 2018 3:35: >> Many C implementations using 32 bit int have a 2G >> file size limit. This happens even if there are >> no fseek() calls. > > Moreover, even on those systems having larger int, there's an issue somewhere > in the common part of code. Sometime, about 128 bytes of mailbox starting at > offset 0 gets overwritten by random bytes, so mailbox become corrupted for > subsequent operations. > > The issue seems not to be related to particular mailbox format driver as I > observed the issue for both UNIX and MBX mailboxes, but it seems to be > related to concurrent access to particular mailbox (e.g. issue related to > locking or so). > > Also, performance penalty for so large files shall be noted. Exim uses either > traditional UNIX format of mailbox or MBX. At least in the first case it take > a lot of time to re-read the mailbox content and some clients are known not > to be patient enough. > > As a result, I'm recommending to keep all mailboxes bellow 2GB of size. Not to mention, for years Mark Crispin adamantly opposed anything greater than 32 bit code (for portability sake). So there may still be dark corners of the UW/Panda IMAP code that will break on a 64 bit system. Just out of curiosity, any reason to stick with the "mbox" format? There are others (EG: 1-file/message & MIX ) which don't have the size limitation and have distinct performance advantages.