Strategy for supporting large message folders

[Kent James]

I was looking today at trying to fix the relatively simple bug 793865 
"nsIMsgParseMailMsgState.envelopePos must be 64bits to support large 
mbox folders", figuring that was one needed step on a relatively small 
path to support >4GB mbox files in local folders. But as I looked into 
it, we have never resolved the issue of a 32 bit nsMsgKey, which also 
equals the message offset in local folders. It is a far from trivial 
issue to make progress on that.

We really need to decide on a path forward with this issue that is 
compatible with the resources that we have available. My fear is that 
any attempt to code around the existing limitations of a 32 bit nsMsgKey 
value would inevitably introduce regressions that would give us years of 
fun times to look forward to in fixing.

What I propose is that instead of doing this, we just admit that local 
mbox folders are limited in size to 4GB, make sure that any usage of 
mbox folders does not allow >4GB operations, and put our efforts instead 
to finishing the remaining issues in maildir support. Bug 793865 would 
be resolved to WONTFIX. Perhaps this represents the existing 
understanding, and I am just out of touch.

Existing 4GB bugs would be resolved by error reporting, preventing 
operations from occurring if they would cause >4GB operations.

There are a couple of 4GB-related bugs on The List. How they are affected:


640371 <https://bugzilla.mozilla.org/show_bug.cgi?id=640371> 	cri 
-- 	Wind 	nobody at mozilla.org 	NEW 	--- 	Local Inbox folder allowed to 
grow past 4GB by mail download 
<https://bugzilla.mozilla.org/show_bug.cgi?id=640371> 	2


This would be resolved by making sure that an "Inbox full" message 
occurs rather than dataloss.


794303 <https://bugzilla.mozilla.org/show_bug.cgi?id=794303> 	maj 
-- 	Wind 	nobody at mozilla.org 	NEW 	--- 	Compact folder fails if local 
mail folder size is near 4GB(less than 4GB) or over 4GB, even though bug 
462665 was changed to FIXED after patch for bug 402392 was landed on Tb 
12.0. <https://bugzilla.mozilla.org/show_bug.cgi?id=794303> 	5


You should be able to compact any valid mbox folder, so this is a valid bug.

:rkent


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20130116/cb96767e/attachment.html>