Closed Bug 341225 Opened 14 years ago Closed 9 years ago
IMAP: Thunderbird caching incomplete downloaded messages
55.60 KB, text/plain
20.32 KB, text/plain
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060508 Firefox/126.96.36.199 Build Identifier: I've seen that an email of about 4mb arrived in my imap-mailbox. Opening it as soon as it has shown up in the mailbox didn't try to download the message, but actually already showed it. Opening fileattachments from the email revealed corrupted attachments (not completely downloaded from server). Closing Thunderbird and reopening the mail had the same result. Reproducible: Sometimes Steps to Reproduce: 1. Receive large email on a "slow" (home-DSL) internet-connection. 2. Open email as soon as it shows up in inbox. 3. Check attachments if any is only partial. Actual Results: Corrupted email shown - and cached (!). Expected Results: Should be downloading the complete email before displaying it. At least it should not cache the only partially downloaded email. Workaround: Using another computer with Thunderbird-IMAP to move mail to a different IMAP folder. When opening the email again on the original client the email is re-downloaded and shows up fine. Moving a corrupted email to a local (!) folder on the client with partially cached email actually leaves the message corrupt, but deletes the correct message from IMAP. So your attachments are "lost".
Component: General → Mail Window Front End
QA Contact: general → front-end
Just confirming that I have also seen this bug: I have seen this on many different computers with several different IMAP servers (Gmail, Mailtrust, etc.). Most recently I've seen it on Thunderbird 188.8.131.52 (Windows/20080914). It happens after an attachment is opened soon after arriving in the Inbox (basically when you only have the headers, or part of the message). Looking at the message source, it has stopped part way through the message/attachment. No errors are thrown. The workaround to get the entire message is as described above: to move it to a different folder so Thunderbird thinks it's new and give it time to actually download the entire message first. This works because the entire message is actually there (can be verified via a web interface, for example) and uses the IMAP COPY command to do a server side copy of the message rather than using the locally cached (incomplete) version. I tried to create an example of this problem. Usually, once Thunderbird shows this problem and has an incomplete cached copy, it thinks it's done and never tried to retrieve the rest of the message. In my example for some reason, it did end up downloading the message again so it worked by the end. I have another test in my Inbox just above this that never did finish, but did not have IMAP logging turned on at the time. I have attached the log anyway since the logs show the message was fully downloaded 3 times! That would be filed under a different bug though, so I won't focus on that here. Besides that, however: everything on the IMAP level looks correct. (Then again, this test did end up working in the end without any workaround.) See the log file for further details. I will also do some more testing with my settings to see if I can recreate the exact problem specified above.
I'm having trouble *consistently* reproducing it. But I think that if you exit Thunderbird while it is downloading the message (for the third time) that it will leave the message in this corrupted state. At the IMAP level, the server gets a LOGOUT command (which I believe it is valid to send a logout command at any time) but the client never recovers from this strange state that it is left in. It'll never try and finish downloading the message. KEY DIFFERENCE between this test and my last: The third download never gets to finish because for some reason it gets a IMAP LOGOUT command: 1032[4ee3978]: 5056bb0:imap.gmail.com:S-INBOX:CreateNewLineFromSocket: w1oYmx9o+cTR/n7n5R9r1COMbR/NHyWfOZ/aW93vyjNCM5Y8N0SJm85u2mq1gndnlx21Y4yrUKqh 0[dd4a58]: 5056bb0:imap.gmail.com:S-INBOX:SendData: 532 logout 0[dd4a58]: 5056bb0:imap.gmail.com:S-INBOX:TellThreadToDie: close socket connection 1032[4ee3978]: ReadNextLine [stream=0 nb=0 needmore=1] I think this is what happens when the attachments are left corrupt... how exactly you happen to get it to do this, I couldn't quite nail down even though I was doing it. I just couldn't tell exactly what combination I was doing that would cause it. Why it downloads the message multiple times at the IMAP level, I'm not sure. What the difference is between "Loading..." and "Downloading message..." in the status bar, I'm not sure. I tried many different combinations -- some ended up correctly saving the attachment (in the end), others stayed corrupted forever. All of them (if you try and save the attachment before it is fully downloaded) would save the attachment corrupt without ANY warning. This bug is specifically about those times where it remains corrupted however. It's just all tied together. Hope this helps!
Please also try it on trunk builds like Shredder Alpha 3: http://www.mozillamessaging.com/en-US/thunderbird/early_releases/downloads.php
Component: Mail Window Front End → Networking: IMAP
Product: Thunderbird → Core
QA Contact: front-end → networking.imap
Bug 468595 is already fixed. (See Bug 468595 Comment #55 for checkin id) Can you reproduce your problem with newest trunk nightly build? > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/ > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1-l10n/ > If MS Win, download win32.zip build. You can test by UNZIP only.
lately upgraded to 3.0b3 from Fedora 11 and _yet_ I didn't have any permanent failure again. So if something went wrong, closing and reopening that message seems to have solved it. One strange thing I did experience was a message where the first half was shown but instead of the mail-footer it said something like "This part of the message body will be downloaded on demand." Well, I had demand :-) Again, closing the mail and reopening it again seems to have solved it.
WFM per reporter
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.