User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Build Identifier: version 0.6 (20040502) When downloading IMAP e-mails with attachments sometimes Thunderbird will not receive the complete attachment. It's a pretty simple problem, and my speculation to why it occours is below. I would venture to guess that the Server stored e-mail environment that IMAP presents combined with the periodic loss of connection we experience with the mail server are contributing factors. But the client should be smart enough to resume attachments, and once the clinet "thinks" it's downloaded an attachment at this point, there is no user friendly way to force a "message reload". This problem is random, and I have no real way of reproducing it, other than sending myself e-mails with large attachments and waiting for one to not work. Reproducible: Always Steps to Reproduce: This problem is random, and I have no real way of reproducing it, other than sending myself e-mails with large attachments and waiting for one to not work. Actual Results: The e-mail attachment must be retrieve via a web-mail based system. Expected Results: Downloaded the attachment fully / provided notification it was incomplete / resumed the attachment Without access to webmail a user would be unable to easily gain access to their attachment. It would basically require exiting TB and deleting your entire IMAP mail folder to get rid of the cached bodys and whatnot.
I've seen this repeatedly on Windows. For a given attachment, the part that downloads is always the same, which made me think that some string of characters was causing it to stop. In one email I received four images and none of the four could be completely downloaded. I was able to get the full attachments using Outlook. I can probably find a few such messages if someone wants me to look at character sequences just after the end of the truncated file. (I think I saw this with Thunderbird 0.6. I haven't been running 0.7 long enough to see this happen, but perhaps it has been fixed.) By the way, the spelling of "attachment" is wrong in the summary, which may make it difficult for people to search for this bug.
Summary: IMAP Attatchment not fully downloaded → IMAP Attachment not fully downloaded
This is very easy to reproduce, and the workaround is also simple, but a dumb one. Definately a bug in IMAP interaction. Note that I confirmed that this bug is ALSO present in Mozilla messenger. Create an email with a number of attachments, at least 8 to 10, size does not seem to matter. Post it to the recipient. If the recipient opens the email and tries to do a "saveall", it will fail. If the recipient saves each attachment 1 [details] [diff] [review] by 1, SOME will fail with zero length. If I use OE to save the attachements from the same email, it will work, so the email has been formed correctly, its just that mozilla/TB does not save it directly out of the IMAP folder correctly. My dumb workaround: If the recipient copies or moves the email to a local folder, then save all & save 1 by 1 will work. It seems to be only related to attachments which are not inline images. (ie. 10 jpgs in an email will display in the email correctly directly from the IMAP folder)
I have seen the exact behavior described by Trevor. Thanks for the workaround, it will save me from having to open Outlook.
what is also interesting is that the linux version which I'm using (0.6) doesn't suffer from this bug (debian unstable)
I think IMAP protocol log is required for developers to analyze problem. See http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap and attach protocol log.
Thanks for the IMAP log pointer, that was very instructive. Unfortunately, I don't see anything in the logs that indicates what the problem is. Here's more detail on my setup: Windows XP Home, Thunderbird 0.7 (20040616), hitting (I think) wu-imap on Gentoo, though I also get this hitting an Exchange Server. Steps that I just took: 1. Create 10 files with this command: dd if=/dev/urandom of=test1.bin count=10 (incrementing the filename counter), creating 10 5k files. 2. Mail them to yourself using Thunderbird. 3. When the message shows up, right-click on any of the attachments and select "Save All...". Choose a directory. 4. Only one of the files is saved (perhaps an unrelated bug). 5. Repeat step 3, confirming that you want to overwrite that one file. 6. Now three files are saved, one of which has 0 bytes. I was able to do steps 3-6 several times (quitting Thunderbird in between). Each time you do a "Save All..." it saves a few more files. Between tests it's not always the same file that has zero bytes. I looked at the IMAP:5 log and found nothing strange, though I don't know the IMAP protocol very well. By "nothing strange", I mean that I don't see any difference between a message whose content saved properly and one that didn't, or anything different about the message that stopped the "Save All" process. In the logs, the following parts are downloaded: 2 (the first attachment, step 3 above), then 3, 4, 5 (step 5 above). Part 2 is only downloaded once, I assume because Thunderbird caches it. Part 3 (second attachment) has zero size when saved to disk, part 4 (third attachment) is saved correctly, and part 5 (fourth attachment) is not saved to disk at all. The IMAP logs show no difference that I could see between any of these downloads. If you'd like me to post specific parts of the log files (or even the whole thing, assuming there's no personal information or passwords in it), let me know. Also, is this related to bug 92111?
*** Bug 248308 has been marked as a duplicate of this bug. ***
Please see bug 92111 for a client-side workaround for this problem, if you're using an Exchange server.
has anyone tried a recent trunk or aviary branch build? I suspect this is fixed by the fix for bug 249195
Assignee: mscott → bienvenu
it's working great!!! - i can't reproduce my download problems! :) i also had problems showing inline-images(cid) sometimes, but that's not a problem anymore either. running thunderbird 20040804
thx, duping. *** This bug has been marked as a duplicate of 249195 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.