On Wed, 31 Aug 2005, S P Arif Sahari Wibowo wrote:
Well, one mailbox (a sent-mail mailbox) just went over 2GB limit (on linux)
and get corrupted.
I was a bit surprised that the problem happened at 2GB instead of 4GB, but
it seems that the stdio fseek() call uses a signed long. I'm surprised
that they didn't expand it when they expanded lseek().
Anyway, this problem will come back again and again in the future. Is there
any way to solve the >GB mailboxes issue without changing the user's
behaviour (since I have no power in that)?
One can make the argument that a user who allows a single mailbox to
exceed 2GB richly deserves whatever punishment is meted out. :-) :-)
More seriously,...!!!
I am looking into how the code can be extended to support more than 2GB in
a portable manner. I have resisted using the fsetpos() interface since it
is documented that fpos_t is not necessarily a byte offset; also, the
implication is that fsetpos() just calls fseek(). I'm going to look at
the source code for Linux's stdio and see what's actually going on as
opposed to what the man page says.
The problem is how to be portable without breaking imapd on some of the
dinosaur systems that people still use as IMAP servers.
The true fix, is a new mailbox format which is designed to scale to 2GB+
sizes. We're working on it...
If I just have a script that rename the old mailbox and create new one every
now and then, is there any possibility it cause corruption to the mailbox if
the user happen to access it at the time (using IMAP server)?
One thing that you could try to do is acquire an exclusive lock on the
mailbox file. If you can acquire that lock, then you can safely rename
the mailbox since nothing has it opened.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
