Mailbox grows endlessly, heavy traffic

Bug #1068921 reported by didi_X8 on 2012-10-20
214
This bug affects 47 people
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Fix Released
High
thunderbird (Ubuntu)
High
Unassigned
Lucid
High
Unassigned
Natty
High
Unassigned
Oneiric
High
Unassigned
Precise
High
Unassigned
Quantal
High
Unassigned

Bug Description

Yesterday I noticed that my Internet connection keeps transferring a lot of data. After a while I checked with nethogs and discovered this was caused by Thunderbird.
Today I got a warning that my HDD was near full.
In this 2 days, the mailbox had grown to 20 GB, while in reality it should be around 1 GB (a fresh zipped backup has 600 MB).

I removed the .thunderbird folder and configured my IMAP mailbox from scratch. The same happened again.
I think this is not related to a somehow special configuration of my PC bcs my colleague discovered it's the same on his machine. Without checking, he wouldn't have noticed yet bcs of a much bigger HDD...

We couldn't yet find out what exactly happens / which data is transferred again and again.
I suspect it's related to the last thunderbird update.

Ubuntu 12.04
Tunderbird 16.0.1+build1-0ubuntu0.12.04.1

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121010234852

Steps to reproduce:

I have dramatically growing mailfiles for subfolders in an IMAP account
This is happening under 16.0.1 under kubuntu. The server appears to be running dovecot:

openssl s_client -connect myhostxxxx.webpack.hosteurope.de:993
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

It was also reporting individual mails with larger (2-5MB) attachments as only having a few (20-30) kb, so my guess is something to do with attachments. Running a repair on the folders fixed it (see below)

I am using this account from a server and a laptop. This may have started when I set up the subfolders (on the laptop as I was traveling) and moved mails into those subfolders. There are two thunderbirds accessing the account at the same time, the server and the laptop (both kubuntu with 16.0.1). The size explosion is happening on the server, and not on the laptop.

I ran out of disk space on /home twice before I saw what the cause was... seems to be as described in bug #463359
I also saw the symptoms as mentioned in bug #802217 with those two folder being continually refreshed (Downloading message x/x in folder1).

INITIAL SIZE:
total 41G
...
-rw------- 1 nils nils 13G Oct 20 15:21 2012-09-folder1
-rw-rw-r-- 1 nils nils 60K Oct 20 15:21 2012-09-folder1.msf
-rw------- 1 nils nils 28G Oct 20 15:49 2012-09-folder2
-rw-rw-r-- 1 nils nils 29K Oct 20 15:49 2012-09-folder2.msf

AFTER REPAIRING ONE IMAP FOLDER
total 13524448
...
-rw------- 1 nils nils 13784117540 Oct 20 15:52 2012-09-folder1
-rw-rw-r-- 1 nils nils 62679 Oct 20 15:52 2012-09-folder1.msf
-rw------- 1 nils nils 43021098 Oct 20 15:51 2012-09-folder2
-rw-rw-r-- 1 nils nils 35978 Oct 20 15:52 2012-09-folder2.msf

AFTER REPAIRING THE SECOND IMAP FOLDER
total 74832
-rw------- 1 nils nils 25172143 Oct 20 15:53 2012-09-folder1
-rw-rw-r-- 1 nils nils 60789 Oct 20 15:53 2012-09-folder1.msf
-rw------- 1 nils nils 43021098 Oct 20 15:51 2012-09-folder2
-rw-rw-r-- 1 nils nils 36180 Oct 20 15:53 2012-09-folder2.msf

didi_X8 (didi156-gmail) wrote :

Update:
The only workaround I found up to now is to turn off offline synchronization.

Also saw this in the Inbox and Sent folders this morning, repairing them fixed the problem- the individual mails had the right size, and the mailbox (which was huge but underreporting its size in the folder pane) as well.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in thunderbird (Ubuntu):
status: New → Confirmed
Steve Magoun (smagoun) wrote :

I've heard of several cases of this in my office this week, all started after Thunderbird on 12.04 was upgraded to 16.0.1 from 16.0

James Ferguson (jamesf) wrote :

A number of us are seeing this problem in our organization. Compacting the mailbox is a temporary fix, but it starts growing again immediately. My INBOX is ~80MB when compacted. Grew to 20GB over a few hours.

didi_X8 (didi156-gmail) wrote :

I think it's the same bug as described here:
https://bugzilla.mozilla.org/show_bug.cgi?id=803326
CPU usage went up for me too.

I'm seeing it again as well on a second machine (laptop accessing the same IMAP account and folders). Inbox reports 6MB with 43 messages... only 4-5 above 500kb (so the summed size in the folder display is consistent with the individual mail sizes _reported_ in the message list). On disk the Inbox has 230MB. And individual mails that have attachments report their size (correctly) in the attachment list at the bottom as 3-4 MB, but are listed as 30kb in the message list.

I have a feeling that this might have something to do with the mail having a graphic in the signature, and separate attachments, but I'm not sure. Those mails are coming from Outlook. I'm fairly sure that this didn't happen with TB15, but not 100% sure.

Bug 803326 may be the same issue. Launchpad has the mailfile size bug which also reports huge mail files: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1068921

I created the report on launchpad.
I'm also connecting to webpack.hosteurope.de
A co-worker reported he also has the issue with another mail provider. I can try to find out what that server is running in order to know if it's related to the server connecting to.

(In reply to Dietmar from comment #5)
> I can try to find out what that server is running in order to know if it's related
> to the server connecting to.

It's also running dovecot (dovecot-imapd 1:1.0.15-2.3+lenny1)

I won't get the chance to do logging in the next few days, but if someone could, that would be great:

export NSPR_LOG_MODULES="imap:5,ImapAutoSync:5,mime:5,mgsdb:5,timestamp,sync"
export NSPR_LOG_FILE=/tmp/tbird.log

See https://wiki.mozilla.org/MailNews:Logging for more info.

From the server login from the logfile:
xxx.webpack.hosteurope.de:NA:CreateNewLineFromSocket: 1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA]

No folders were growing at this point.

Changed in thunderbird:
importance: Unknown → Medium
status: Unknown → New

Can any of ou seeing the issue give Irving (on the cc mist) access to such a server so he can investigate ?

James Ferguson (jamesf) wrote :

As per the request in bugzilla comment 7, here is the log from running up thunderbird. Before the run I compacted the INBOX (to about 18MB IIRC). INBOX had no business growing (no new mail during the run), but it tripled in size in a couple of minutes. There were 440 messages in it.

(username & server name modified in this log) - it is Dovecot.

So, the first broken nightly appears to be https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/06/2012-06-20-03-02-01-comm-central/thunderbird-16.0a1.en-US.linux-x86_64.tar.bz2

(https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/06/2012-06-19-03-02-01-comm-central/thunderbird-16.0a1.en-US.linux-x86_64.tar.bz2 works ok)

I've also tracked it down to a specific message too. There seems to be 2 issues at play:
1) That the message is saved offline at all, as it is larger than the 50kB limit
2) When it is downloaded it never seems to get marked as available offline, so it is downloaded repeatedly every time the folder is updated (and ends up in the mbox file multiple times)

Created attachment 674310
Message which triggers it

Here is a message which triggers it. Fortunately, it only contains spam :)

Just waiting for my local checkout to build so that I can do a proper bisect, but these 2 commits might be a clue:

changeset: 10468:5a6bee217340
user: Irving Reid <email address hidden>
date: Tue Jun 19 08:55:19 2012 -0700
summary: Bug 92111 (and bug 390795, and many others) - correctly handle case where we're downloading IMAP body in chunks, and the server lies about RFC822.SIZE,r=bienvenu

changeset: 10469:0401e822b882
user: Irving Reid <email address hidden>
date: Tue Jun 19 09:00:03 2012 -0700
summary: Bug 740453: Investigate download whole message vs. download in chunks,r=bienvenu

Is somebody with the bug willing to test whether it's related to the offline message size limit? Open the Mail Server properties for a folder showing this problem (right click on the mail server, select "Settings...", select the "Synchronization and Storage" settings, and check whether you have "Don't download messages larger than x KB" checked.

If you do have it checked, try un-checking it and see if the problem goes away - your client should download the large messages one more time and then stop.

I've been looking at the log file on the Launchpad bug, and that log only shows us downloading each of the large messages once.

Irving: I do not have it checked and am seeing the issue (re Comment 14)

I've reproduced what I think is this issue on OS X against gmail's IMAP server. The problem comes in two parts, and so far I think I have a fix for part 1. I'll put up a WIP patch.

Created attachment 674524
WIP: Call DiscardNewMessage() with non-null stream to avoid early exit

This is part 2 of the fix, when we detect a mismatch between the expected size of a message and the actual size we try to take the message back out of the local store. Because of some interactions with parameter-validity checking, the downloaded message contents weren't actually removed from the local mbox file. This would cause the file to grow, but shrink back to proper size when the folder is compacted.

The immediate trigger for the problem is that we're getting a bogus size for the message at http://mxr.mozilla.org/comm-central/source/mailnews/base/util/nsMsgDBFolder.cpp#1707; I haven't figured out why that's happening yet.

Changed in thunderbird:
status: New → In Progress

(In reply to Chris Coulson from comment #13)
> summary: Bug 92111 (and bug 390795, and many others) - correctly handle
> summary: Bug 740453: Investigate download whole message vs. download in

nice detectiving! will let you all sort this out

I set a breakpoint in nsMsgDBFolder::EndNewOfflineMessage() to trigger when this condition occurs, and I made a note of various local variables when it happens (hopefully it will be useful):

Main thread:
tellPos = 4450254
messageOffset = 4271281
curStorePos = 178973
m_offlineHeader->GetMessageSize() returns 1778
m_bytesAddedToLocalMsg = 83
m_numOfflineMsgLines = 2447

On the IMAP thread (in nsImapProtocol::NormalMessageEndDownload()):
m_bytesToChannel = 178890
m_parser.fSizeOfMostRecentMessage = 178890

Download full text (10.3 KiB)

Ok, some more info now. With the message attached to this bug report, if I break in nsMsgDBFolder::EndNewOfflineMessage() then I see the following:

Breakpoint 9, nsMsgDBFolder::EndNewOfflineMessage (this=0x7fffca4bb400) at /home/chr1s/src/thunderbird/comm-central/mailnews/base/util/nsMsgDBFolder.cpp:1719
1719 mDatabase->MarkOffline(messageKey, false, nullptr);
(gdb) p messageSize
$15 = 4294959567
(gdb) p m_numOfflineMsgLines
$16 = 11791
(gdb) p m_bytesAddedToLocalMsg
$17 = 83
(gdb) p curStorePos
$18 = 731268
(gdb) p messageSize + m_numOfflineMsgLines - m_bytesAddedToLocalMsg
$19 = 3979
(gdb) t 22
[Switching to thread 22 (Thread 0x7fffc9dff700 (LWP 22310))]
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
162 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
(gdb) f 7
#7 0x00007ffff30fb7b1 in nsImapProtocol::NormalMessageEndDownload (this=0x7fffcabae000) at /home/chr1s/src/thunderbird/comm-central/mailnews/imap/src/nsImapProtocol.cpp:3941
3941 m_imapMessageSink->NormalEndMsgWriteStream(m_downloadLineCache->CurrentUID(), imapAction == nsIImapUrl::nsImapMsgFetch, m_runningUrl, updatedMessageSize);
(gdb) p m_bytesToChannel
$20 = 731185
(gdb) p m_parser.fSizeOfMostRecentMessage
$21 = 731185

So, the amount of data downloaded matches the size from the server (731185), but doesn't match the size stored in the summary file (3979). Running with NSPR_LOG_MODULES="imap:5,ImapAutoSync:5,mime:5,mgsdb:5,timestamp,sync", I see this logged (uninteresting bits removed):

2012-10-24 17:37:28.538382 UTC - -908069120[7fffca734150]: ca2bd800:imap.googlemail.com:S-[Google Mail]/Test:SendData: 9 UID fetch 2:3 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type List-id X-Bugzilla-URL X-Launchpad-Bug X-Generated-By X-Launchpad-Message-Rationale X-Launchpad-Build-State)])
2012-10-24 17:37:28.588550 UTC - -908069120[7fffca734150]: ReadNextLine [stream=ca7fb3a0 nb=370 needmore=0]
2012-10-24 17:37:28.588614 UTC - -908069120[7fffca734150]: ca2bd800:imap.googlemail.com:S-[Google Mail]/Test:CreateNewLineFromSocket: * 1 FETCH (X-GM-THRID 1416729568466002411 X-GM-MSGID 1416729568466002411 X-GM-LABELS () UID 2 RFC822.SIZE 731185 FLAGS (\Seen) BODY[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type List-id X-Bugzilla-URL X-Launchpad-Bug X-Generated-By X-Launchpad-Message-Rationale X-Launchpad-Build-State)] {357}
2012-10-24 17:37:28.596380 UTC - -908069120[7fffca734150]: ca2bd800:imap.googlemail.com:S-[Google Mail]/Test:STREAM:OPEN Size: 731185: Begin Message Download Stream

  ** snip **

2012-10-24 17:37:31.973178 UTC - -908069120[7fffca734150]: ca2bd800:imap.googlemail.com:S-[Google Mail]/Test:SendData: 12 UID fetch 2 (BODYSTRUCTURE)
2012-10-24 17:37:32.030042 UTC - -908069120[7fffca734150]: ReadNextLine [stream=ca7fb3a0 nb=291 needmore=0]
2012-10-24 17:37:32.030089 UTC - -908069120[7fffca734150]: ca2bd800:imap.googlemail.com:S-[Google Mail]/Test:Create...

Changed in thunderbird:
importance: Medium → High
Changed in thunderbird (Ubuntu):
importance: Undecided → High
Changed in thunderbird (Ubuntu Natty):
importance: Undecided → High
Changed in thunderbird (Ubuntu Oneiric):
importance: Undecided → High
Changed in thunderbird (Ubuntu Natty):
status: New → Triaged
Changed in thunderbird (Ubuntu Lucid):
importance: Undecided → High
Changed in thunderbird (Ubuntu Precise):
importance: Undecided → High
Changed in thunderbird (Ubuntu Quantal):
importance: Undecided → High
Changed in thunderbird (Ubuntu Lucid):
status: New → Triaged
Changed in thunderbird (Ubuntu Oneiric):
status: New → Triaged
Changed in thunderbird (Ubuntu Precise):
status: New → Triaged
Changed in thunderbird (Ubuntu Quantal):
status: New → Triaged
Changed in thunderbird (Ubuntu):
status: Confirmed → Triaged

*** Bug 805265 has been marked as a duplicate of this bug. ***

Sian Aherne (sian-aherne) wrote :

I tried to Compact my email folders, but the error messages said: "The folder 'NAME' could not be compacted because writing to the folder failed. Verify that you have enough disk space, and that you have write priviledges to the file system, then try again"

Peter Matulis (petermatulis) wrote :

Automatic compacting does not seem to be working either. See bug #1071364 .

*** Bug 804100 has been marked as a duplicate of this bug. ***

Created attachment 675206
Only correct the message size when storing the message offline

Would something like this be sufficient to stop the wrong size being saved in the database? It seems to do the trick here, but I'm not familiar with this code enough to know if it breaks something else

Created attachment 675293
Fix broken size in message db

This fixes the broken size in the message db. Again, I'm not really sure if this takes the right approach, as I'm completely unfamiliar with this code :/

With those changes applied, I see this when I start thunderbird for the first time:

WARNING: Underflow occurred: 'underflowed == false', file /home/chr1s/src/thunderbird/comm-central/mailnews/base/util/nsMsgDBFolder.cpp, line 1721
WARNING: Repairing message size in db: oldSize=3979, newSize=731185: file /home/chr1s/src/thunderbird/comm-central/mailnews/base/util/nsMsgDBFolder.cpp, line 1766

The size is now correct and it has successfully stored the message offline

I'm not comfortable with this approach; the message size we get (which is actually the size of one text part of the message, accidentally set when downloading parts of a MIME multipart message separately) is not guaranteed to be larger or smaller than the number of line breaks in the entire message. It usually is, for very large messages, but this won't be reliable.

I'm pretty close to having a clean way to not record the wrong size when we're downloading a part. I'm not sure how it will work for users with and existing wrong size in their message DB, they may need to manually rebuild the folder.

Created attachment 675465
Test message with many inline images

When I set the checkbox for maximum message size to store offline, with a limit of 50 kbytes, this message gets downloaded very inefficiently - each image attachment is requested from gmail separately, but for each inline image displayed we download the entire message (including separate downloads of each inline part) - order n^2 on the number of inline attachments.

Un-checking the limit on offline message store significantly reduces the problem.

Created attachment 675468
call DiscardNewMessage properly, only update size when downloading full message

This includes my previous patch and also keeps track of when we're downloading an entire message, and only updates the message size in the DB on entire message downloads. This patch seems to fix the example message provided with the original report, after manually compacting or repairing the folder.

While testing this I noticed that there is still a form of message that behaves badly whether this patch is applied or not; I attached an example of that message. I haven't debugged that issue yet.

Changed in thunderbird:
importance: High → Medium

Comment on attachment 675468
call DiscardNewMessage properly, only update size when downloading full message

Review of attachment 675468:
-----------------------------------------------------------------

This looks fine afaict. It seems to do the right things and doesn't break existing tests.

::: mailnews/base/util/nsMsgDBFolder.cpp
@@ +1721,5 @@
> + ReleaseSemaphore(static_cast<nsIMsgFolder*>(this));
> + if (msgStore)
> + // this closes the stream
> + msgStore->DiscardNewMessage(m_tempMessageStream, m_offlineHeader);
> + else

nit: blank space on end of line

::: mailnews/imap/src/nsImapProtocol.cpp
@@ +3270,5 @@
>
> if (NS_SUCCEEDED(rv))
> ParseIMAPandCheckForNewMail(commandString.get());
> GetServerStateParser().SetFetchingFlags(false);
> + m_fetchingWholeMessage = false;

For the two false cases, please can you include the comment:

// Always clear this flag after every fetch.

as I think it'll just help make it a bit more sense (and reflects what was there before)

I possibly have another related issue... please let me know if it warrants a new bug. Moving one of these messages (not sure if it triggers it, but its in a folder and of a style where it happens often) to a subfolder shows it not arriving in the subfolder. I opened the subfolder on another machine and it was there, restarting tbird on the first machine and going to the folder made it show up there as well. So no data loss, but temporary disappearance.

*** Bug 806172 has been marked as a duplicate of this bug. ***

Marking as fixed for tracking purposes. This will be released in 16.0.2 later today.

Irving, please spin out the separate case into a new bug. If folks are still seeing issues, please check that new bug, and/or file a bug for your own issue.

*** Bug 802217 has been marked as a duplicate of this bug. ***

Mozaic (mozaic) wrote :

https://bugzilla.mozilla.org/show_bug.cgi?id=803843#c33
"Marking as fixed for tracking purposes. This will be released in 16.0.2 later today.

Irving, please spin out the separate case into a new bug. If folks are still seeing issues, please check that new bug, and/or file a bug for your own issue."

Need an update to 16.0.2

Chris Coulson (chrisccoulson) wrote :

There's no need to subscribe me directly to Mozilla bugs, and I started the builds for 16.0.2 yesterday already

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunderbird - 16.0.2+build1-0ubuntu0.12.04.1

---------------
thunderbird (16.0.2+build1-0ubuntu0.12.04.1) precise-security; urgency=low

  * New upstream stable release (THUNDERBIRD_16_0_2_BUILD1)
    - see LP: #1072362 for USN information

  * Only update the message size in the db when downloading the whole message
  * Don't call DiscardNewMessage with a closed stream
  * Fixes LP: #1068921
 -- Chris Coulson <email address hidden> Sun, 28 Oct 2012 14:29:01 +0000

Changed in thunderbird (Ubuntu Precise):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunderbird - 16.0.2+build1-0ubuntu0.10.04.1

---------------
thunderbird (16.0.2+build1-0ubuntu0.10.04.1) lucid-security; urgency=low

  * New upstream stable release (THUNDERBIRD_16_0_2_BUILD1)
    - see LP: #1072362 for USN information

  * Only update the message size in the db when downloading the whole message
  * Don't call DiscardNewMessage with a closed stream
  * Fixes LP: #1068921
 -- Chris Coulson <email address hidden> Sun, 28 Oct 2012 14:30:19 +0000

Changed in thunderbird (Ubuntu Lucid):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunderbird - 16.0.2+build1-0ubuntu0.12.10.1

---------------
thunderbird (16.0.2+build1-0ubuntu0.12.10.1) quantal-security; urgency=low

  * New upstream stable release (THUNDERBIRD_16_0_2_BUILD1)
    - see LP: #1072362 for USN information

  * Only update the message size in the db when downloading the whole message
  * Don't call DiscardNewMessage with a closed stream
  * Fixes LP: #1068921
 -- Chris Coulson <email address hidden> Sun, 28 Oct 2012 14:21:56 +0000

Changed in thunderbird (Ubuntu Quantal):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunderbird - 16.0.2+build1-0ubuntu0.11.10.1

---------------
thunderbird (16.0.2+build1-0ubuntu0.11.10.1) oneiric-security; urgency=low

  * New upstream stable release (THUNDERBIRD_16_0_2_BUILD1)
    - see LP: #1072362 for USN information

  * Only update the message size in the db when downloading the whole message
  * Don't call DiscardNewMessage with a closed stream
  * Fixes LP: #1068921
 -- Chris Coulson <email address hidden> Sun, 28 Oct 2012 14:29:46 +0000

Changed in thunderbird (Ubuntu Oneiric):
status: Triaged → Fix Released
Evangelos Stravoudakis (estra) wrote :

This bug fix, will also work retroactively and fix the problems the previous TB version created?
Will it restore to it normal size the Huge mailboxes, and restore the space in our HD?

Does anyone know?

If not, what are the steps we need to take, in order the remedy the problem?

Can anyone point to a link with the solution?

Reopened bug 802217 as bug 806760 as that issue (constantly redownloading mails, even though now the mailfile size is not growing any more -- thanks!) is not fixed.

Changed in thunderbird:
status: In Progress → Fix Released
Evangelos Stravoudakis (estra) wrote :

I confirm too that the bug is still there.
The /home folder does not get smaller, but the downloading still goes on.

nils (internationils) wrote :

Compacting the folder reduces the size, but it still causes repeating downloads. Repairing the folder should stop those as well. See https://bugzilla.mozilla.org/show_bug.cgi?id=806760

Even after updating to 16.0.2, compacting, and repairing my large "All Mail" folder, I still have the problem of Thunderbird endlessly downloading my mail.

Note that while repairing my folder Thunderbird got to the point where it said it was "Downloading 9215 of 9209 messages".

didi_X8 (didi156-gmail) wrote :

For me it seems to be fixed. Did you restart Thunderbird after the update?

Evangelos Stravoudakis (estra) wrote :

I restarted TB plenty of times.
As a matter of fact, I have to because every time TB is open, it clogs my internet line.

Are there specific steps someone has to take to fix the situation AFTER he/she updates?

nils (internationils) wrote :

Read comment #53. You need to repair the folder (richt click -> properties).

Evangelos Stravoudakis (estra) wrote :

Nope it doesn't work for me :(
I compacted and repaired all my Inboxes.

It still downloads like crazy... arghh... it's frustrating...

Sleft (sleft) wrote :

For me the endless dowloading was fixed by unchecking "Keep messages for this account on the computer" under Synchronization & Storage in the Account settings for the affected email account. See http://askubuntu.com/a/209959/19490

Evangelos Stravoudakis (estra) wrote :

I thing that would have fixed the problem regardless whether you upgraded or not.
Since this check box, would stop TB from saving locally the e-mails from the imap server.

So although this is a "fix", it stops a big part of the functionality of TB.

Please correct me if I am mistaken.

nils (internationils) wrote :

Can someone who has time please close this bug, open another one for the heavy IMAP traffic, and link it to https://bugzilla.mozilla.org/show_bug.cgi?id=806760 ? Thanks...

nils (internationils) wrote :

Created a new bug for the second issue (continually redownloading messages): https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1074260

802217 seems not to be reopened. And it is _not_ the same. Please reopen 802217.

Just found 806760, sorry.

Adolfo Jayme (fitojb) on 2013-02-05
Changed in thunderbird (Ubuntu Natty):
status: Triaged → Won't Fix
Rolf Leggewie (r0lf) wrote :

is this fixed in raring and saucy?

Changed in thunderbird (Ubuntu):
status: Triaged → Incomplete
Yo (yleduc) on 2015-04-10
Changed in thunderbird (Ubuntu):
status: Incomplete → Fix Released
Changed in thunderbird:
importance: Medium → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.