Re: Strategy for supporting large message folders

acelists at atlas.sk acelists at atlas.sk
Thu Jan 17 07:50:50 UTC 2013


Hi.
As l long as the limit is consistently applied (and presented to the user) in all circumstances I am OK with that plan.
But I think you should also make those limits explicit in the code so that even developers know what they are.
Also, I think the limit on FAT is still 2GB so the limit should be a nsIMsgIncomingServer property, getting initialized when TB is started and the filesystem of the Local Directory is analysed.

aceman
______________________________________________________________
> Od: "Kent James" <kent at caspia.com>
> Komu: <tb-planning at mozilla.org>
> Dátum: 16.01.2013 23:17
> Predmet: Strategy for supporting large message folders
>
>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.



More information about the tb-planning mailing list