491088 - Email is getting the "This body part will be downloaded on demand." message on display.

Status: VERIFIED DUPLICATE of bug 468637

(Thunderbird :: Mail Window Front End, defect)

Description

[Michael Baffoni]

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b5pre) Gecko/20090501 Shredder/3.0b3pre

I've gotten a message with the dreaded "This body part will be downloaded on demand." message on one of my emails.  I have my INBOX configured to sync to the local system, I thought I would never get this again, obviously the sync didn't complete the get of the entire message....

This is really odd because I saw all of the contents of the message when it first came in, I then clicked on another message, then came back to this one and only THEN got the error message.

So far no other messages have shown this error (today).

Here is a partial copy of the source from an email with this problem (note the first attachment is a .jpg that also has the same error, although I the second attachment (name changed) which does show and downloads correctly).

----------------------------------------------------------------------------
Content-Type: multipart/mixed;
 boundary="------------030207040909070202080902"

--------------030207040909070202080902
Content-Type: multipart/alternative;
 boundary="------------000501020608000800020003"

--------------000501020608000800020003
X-Mozilla-IMAP-Part: 1.1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This body part will be downloaded on demand.
--------------000501020608000800020003
Content-Type: multipart/related;
 boundary="------------070804090906000002030306"

--------------070804090906000002030306
X-Mozilla-IMAP-Part: 1.2.1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This body part will be downloaded on demand.
--------------070804090906000002030306
X-Mozilla-IMAP-Part: 1.2.2
Content-Type: image/jpeg;
 name="kitty.jpg"
Content-Transfer-Encoding: base64
Content-ID: <[e-mail]>
Content-Disposition: inline;
 filename="kitty.jpg"

This body part will be downloaded on demand.
--------------070804090906000002030306--
--------------000501020608000800020003--
--------------030207040909070202080902--
Content-Type: application/msword;
 name="[snippedfilename].doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename*0="[snippedfilename].doc"

----------------------------------------------------------------------------

Comment 1

[rsx11m]

Is this related to your bug 468637 filed before? I'm trying to figure out what the difference is... ;-)

I'm only occasionally using local offline storage for testing, but ran into this issue as well some time ago and was unable to reproduce it later. Downloading the message for display and then downloading it for offline storage appear to be two different processes, thus interrupting the offline download of a complex multi-part message seems to result in those "on demand" entries rather than the actual attachment being downloaded. It's not added later either, I recall having to physically remove the offline storage version (or the entire folder) to get it complete on my next visit to that message.

Comment 2

[Michael Baffoni]

You are correct, I was thinking the other bug was closed becuase I lost the message, duping.