243548 - IMAP Attachment not fully downloaded

Status: RESOLVED DUPLICATE of bug 249195

(Thunderbird :: General, defect)

Description

[Matt Westfall]

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.

Comment 1

[Lawrence Kesteloot]

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.

Comment 2

[Trevor Nuridin]

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)

Comment 3

[Lawrence Kesteloot]

I have seen the exact behavior described by Trevor.  Thanks for the workaround,
it will save me from having to open Outlook.

Comment 4

[Trevor Nuridin]

what is also interesting is that the linux version which I'm using (0.6) doesn't
suffer from this bug (debian unstable)

Comment 5

[WADA:World Anti-bad-Duping Agency]

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.  

Comment 6

[Lawrence Kesteloot]

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?

Comment 7

[hansen]

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

Comment 8

[David :Bienvenu]

Please see bug 92111 for a client-side workaround for this problem, if you're
using an Exchange server.

Comment 9

[David :Bienvenu]

has anyone tried a recent trunk or aviary branch build? I suspect this is fixed
by the fix for bug 249195

Comment 10

[hansen]

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

Comment 11

[David :Bienvenu]

thx, duping.

*** This bug has been marked as a duplicate of 249195 ***