What is the limit on number of messages in one mailbox in Thunderbird?
What is the limit on number of messages in one mailbox in Thunderbird?
My question is about Thunderbird 45.5.1. I know the program is quite old, however.
The mailboxes are stored locally (so POP, not IMAP). All messages are stored in one file (and yes, I know that newer versions allow to store each message as individual file).
And yes, I know that size limit of a mailbox in this version is 4 GB.
Valittu ratkaisu
Each message in a folder has a number. The result of that can be seen in the GUI by displaying the order received column. The structure of the MSF that indexes the file can only hold 4 billion references. Storage method is not all that relevant here. My understanding is that compacting, but creating a completely new file get a new set of reference numbers in the process, so the limit would be 4 billion visible and hidden (deleted) mails per folder.
Having said that I think there would be issues with memory management long before that technical limit arrived. Such an MSF would simply most likely be to large for memory.
Lue tämä vastaus kontekstissaan 👍 1Kaikki vastaukset (6)
Four billion: http://kb.mozillazine.org/Limits_(Thunderbird)#Folders_and_messages
The limit on size is usually reached before the limit on number.
sfhowes said
Four billion: http://kb.mozillazine.org/Limits_(Thunderbird)#Folders_and_messages The limit on size is usually reached before the limit on number.
Thank you. I read that page before. I thought this limit applies when each message is stored as an individual file in the folder (i.e., maildir storage format). Or it this same limit on number of messages when all messages are stored in one file (i.e., mbox storage format)?
dima8 said
Thank you. I read that page before. I thought this limit applies when each message is stored as an individual file in the folder (i.e., maildir storage format). Or it this same limit on number of messages when all messages are stored in one file (i.e., mbox storage format)?
I think the limit applies to mbox storage, since the bug report is 5 years old, before maildir was an option in TB.
sfhowes said
I think the limit applies to mbox storage, since the bug report is 5 years old, before maildir was an option in TB.
Actually, I found that maildir is an option starting Version 38.0.1 released June 11, 2015 [see https://www.thunderbird.net/en-US/thunderbird/38.0.1/releasenotes/ ], and even before in beta version [see https://www.thunderbird.net/en-US/thunderbird/38.0beta/releasenotes/ ], while the bug is opened a year later (on 2016-04-01) and they're discussing later Version 38.7.1.
However, in this bug they are not discussing whether mbox or maildir format was used - so it suggests that the limit may be the same. While this is just a guess, and it's still not certain, through.
Valittu ratkaisu
Each message in a folder has a number. The result of that can be seen in the GUI by displaying the order received column. The structure of the MSF that indexes the file can only hold 4 billion references. Storage method is not all that relevant here. My understanding is that compacting, but creating a completely new file get a new set of reference numbers in the process, so the limit would be 4 billion visible and hidden (deleted) mails per folder.
Having said that I think there would be issues with memory management long before that technical limit arrived. Such an MSF would simply most likely be to large for memory.
Matt said
Each message in a folder has a number. The result of that can be seen in the GUI by displaying the order received column. The structure of the MSF that indexes the file can only hold 4 billion references. Storage method is not all that relevant here. My understanding is that compacting, but creating a completely new file get a new set of reference numbers in the process, so the limit would be 4 billion visible and hidden (deleted) mails per folder. Having said that I think there would be issues with memory management long before that technical limit arrived. Such an MSF would simply most likely be to large for memory.
Thank you. Apparently it is.