The attached .zip-file of one of my messages has a "4.9 MB" next to it. When clicking on it, the download window (the window with "Open with..." and save in it) says 6.7 MB. Actual file size = 5,116,315 Byte = 4.88 MByte (Uncompressed file size = 5,640,665 = 5.40 MByte) The 6.7 MB are clearly wrong. Same happens with a mp3. (size shown below the message: 4.9 MB, in download window: 6.3) and a small gif (36.5 KB vs 53,6 KB) and a small textfile (975 bytes vs 3,0 KB)
The values presented next to the attachment show the actual size of it after unpacking (Jim: correct?), whereas the overall message size has a third+ overhead due to the base64 encoding, and that's what's apparently also used for the download window.
to clarify: i'm talking about the problem visible in the image attached. i didn't fully understand what rsx11m wrote, but i was not talking about the message size :)
Thanks for the screen shot. The calculation you presented in your initial description would have matched my assumption in comment #1, but 975 KB is clearly much less than what would explain the 3.0 MB stated download size in the window. Thus, my only guess is if that message overall is 3.0 MB in size, the download manager mistakenly states the full message size as the target size rather than the actual size of the attachment to be extracted.
(and I'm off by a factor of 1024, that's 975 bytes vs. 3.0 KB of course...)
the size in the download window matches the size for the message as shown in the "size"-column of the message list. i also tested it with multiple attachments, their size is correctly shown in the message (both 975 Byte), the message size in the "size"-column is reasonable (4.0 KByte), and the size of each attachment shown in the download window is 4.0 KByte.
Confirming, the stated target size is always the full and encoded message, whereas the actual progress is shown based on the decoded attachment (thus ending around 73% progress if the attachment occupies most of the message). This also applies to multiple attachments depending on their proportion to the full message. Since I can also reproduce this on SeaMonkey it's apparently a MailNews Core issue calculating the download target and current progress. The target should correspond to the actual number of bytes to be downloaded (i.e., the selected attachment or the sum of all attachments to be saved). I can't find this filed yet.
Status: UNCONFIRMED → NEW
Component: General → Attachments
Ever confirmed: true
Product: Thunderbird → MailNews Core
QA Contact: general → attachments
Version: 10 → Trunk
Summary: Download window shows wrong file size → Download window shows wrong file size (full message size, not attachment size)
I tried this with a few different cases, and it only happens for me in the Open dialog. The Saved Files dialog always shows the right size (I tested with opening and saving IMAP and POP messages).
Created attachment 8466118 [details] wrong file size for both files I got two files per mail. One file was 2,9 MB, the other one 842 KB. I did "save as.." on both files. The download window showed me 5,1 MB for each file.
Created attachment 8466121 [details] 2nd try: correct file size, wrong file name i reastarted Seamonkey, emptied the download list and tried again: now i got the correct file size for both size, but one file got a strange name.
Created attachment 8466123 [details] 3rd try: everything is fine on my 3rd try everythings was like expected. this means that the bug doesn't appear always.
I had the same problem in SeaMonkey 2.26.1 and attached some pictures. It's interesting that I got thre different results in three tries. The original mail header concerning the mail parts was like: Content-Type: multipart/mixed; boundary="------------090303080604000105070707" --------------090303080604000105070707 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit --------------090303080604000105070707 Content-Type: application/pdf; name="file1.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="file1.pdf" --------------090303080604000105070707 Content-Type: application/pdf; name="file2.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="file2.pdf"
You need to log in before you can comment on or make changes to this bug.