User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; sv-SE; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Thunderbird 3.0b4 See above Reproducible: Always

Please update to Thunderbird 3 RC1 or RC2 (RC2 should be out later today). I expect you are using gmail, hence this issue is already fixed.

And we fixed a similar issue on exchange too.

Lars, are you using exchange or gmail?

Lars ?

I seem to have the same issue, with thunderbird 3 final, on my company's mail (I cannot tell you just now what mailserver is that, i'll have to ask). What's strange is that it seems to happen only for some of the folders, not all. From time to time it would just reload the whole folder, and say "downloading message x from y" or "downloading message header x from y". This way, one of the folders that would have a couple of megs (2.5) ended up at 14G. For now, I disabled offline storage for those folders and it seems to be fine, the size stays 'normal'. Now, I've been running thunderbird3 since beta 3 (and kept upgrading), I think, and I didn't start with a clean profile when I started, I used my old thunderbird 2 folder. I'm on an ubuntu 9.10.

Anca , Lars can you guys tell use which servers you are getting your emails from ?

I'm seeing a similar error (TB 3.0 on OS X 10.6 32bit intel). Every time a folder is accessed (new mail arrives or I click on it to browse mail contents) TB starts synchronizing a selection of messages (followed by a gloda indexing of them). I have the impression that it are always the same messages that are downloaded and indexed over and over again (at least the number of messages downloaded at each cycle is unaffected). The size of the msf file as well as the mailbox file in the ImapMail folder in the profile increases at each occurrence. A workaround for the ever increasing size of the offline mailbox folder storage is to compact them manually (automatic compacting is not triggered even if set--but that's probably a different bug). That first increases the size of the mailbox as accessing them triggers synchronising, but subsequently they are slimmed down again. The synchronising and indexing cycles are very hungry in their resource use, which means that they are draining battery power when working unplugged and online. And they are hungry in bandwith as well. As for the size of the gloda index file it's unclear to me what happens over time. These resources are managed by sqlite which follows a different (and more advanced) scheme for allocating disk space. I'm not sure if the issue is specific to TB 3. I noticed that after starting with a vanilla profile in TB 3 the ImapMail folder is now much smaller than the one in my existing TB 2 profile (bot of which are synchronised to the same folders). In TB 2 I had automatic compacting set but noticed that it would only be triggered when starting up offline (which happened regularly for files in the Mail folder of the profile but I cannot recall to have seen it happen to ImapMail contents). I'm accessing an Exchange server over IMAP.

I've been further researching the issue. Re-indexing the folder doesn't change things: the same messages get downloaded again and again. So it's the content of the messages causing havoc. In the IMAP log I see that after setting up the connection and listing the folders a first (subfolder) is selected and the message UIDs are fetched. Immediately after that a first message is downloaded (one that is already available offline). So there's not much said before it goes wrong. It's my guess that there must be something in the msf file that triggers TB to start fetching a message with a specific UID. I don't understand much from the morked msf file, but I can make up that the first messages to be fetched all have in the msf file the recipients list defined by a value in the message record, rather than by a hex oid with a value for the oid defined elsewhere (as is done for the other unfetched messages). Not sure if that makes sense, and even less sure how the difference arises. What I can make up is that the messages selected for redownload have a couple of rather verbose addresses in the recipient list, such as =?us-ascii?Q?mw=2Edr=2E_Jos_Bros=2C_Dept=2E_Mus_Mux_ZDS_EUR__Chef_Nu?= =?us-ascii?Q?ddes_51=3B_room_R52-41_5065_XV_D=27NUX_T=3A0128235124/F=3A0?= =?us-ascii?Q?325208543_?= <josbros@the.org> (I randomised personal information in the address for privacy reasons). Although that's fine according to the Mork spec, it may be less fine for a particular implementation of it. [rhetoric mode]Has it been suggested before to get rid of Mork?[/rhetoric mode] I'm not sure how the MIME-encodings ended up in the msf file. They figure as such in the IMAP-log. I also see addresses which have a mime encoding =29 which is a close paren. Does it get resolved without proper escaping before the database is parsed? Just guessing. Anyways, I think this bug should be fixed sooner rather than later. Thunderbird is downloading messages over and over again like there's no tomorrow. Just starting it up causes an IMAP-log of over 50MB in size. My ImapMail folder doubled in size in just two days of relatively calm traffic.