User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:184.108.40.206) Gecko/20110414 Thunderbird/3.1.10 My Thunderbird IMAP mailbox has an incoming mail with a ZIP file attached. Saving the ZIP file results in 746224 bytes, and the file is unreadable, although appears binary, and the start is certainly a ZIP header. Browsing my mail through an alternative online method and saving the file gives 1023790 bytes, and a working ZIP file. Reproducible: Always Steps to Reproduce: By "Every time", I mean every time with this particular email - I've restarted thunderbird and retried viewing the mail - same problem. But it hasn't happened before with other mails. Actual Results: ZIP is invalid and truncated. Expected Results: Save the full untruncated file, as webmail alternative does.
Just to add, it is a truncation - the 746224 bytes saved by Thunderbird are the same as the first 746224 bytes of the complete zip file.
can you get us a imap log when you are trying to get this file. It would help investigate what's going on. <https://wiki.mozilla.org/MailNews:Logging>.
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Version: unspecified → 1.9.2 Branch
Yep - the log file is too big to upload, so here is a link:- http://www.teapotrecords.co.uk/tblog/imap.txt Sorry about the size - best I could do, even emptying my inbox to trim it. In the process, I now have a way to reproduce the problem consistently, by sending the email to myself. The log records just the following actions - starting with empty inbox. 1. Send e-mail to email@example.com (me), attaching working zip-file "c:\cs2.zip", of size 1,023,790 bytes. 2. Mail is sent successfully, and copied to sent folder successfully. 3. The new mail arrives. 4. I right click on the attachment "cs2.zip", Save as, C:\Cs2-resend.zip 5. C:\Cs2-resend.zip has size 747,754, and is invalid. I've repeated this twice now to check it is repeatable. Hope this helps.
Can you try to trim down the log ?
Whiteboard: [has protocol logs]
Tricky... partly because I don't really understand the IMAP protocol - I don't know quite what you need to see. But also because the only things included in the log (as far as I can make out), are the actions that trigger the reproducible problem, so I'm not really sure what I can omit, while still enabling you to find what's happening. I'll try some other tests and see if I can get the same behaviour with other smaller files, which should make the log smaller.
OK, I know what it is. After more testing, I found that the problem did not occur when I went exclusively through my gmail account, rather than my college account, which is an Exchange server. I then found that they'd recently upgraded/change their version of Exchange... and that there are some reports of their latest one *mis-reporting* the size of attachments. Stunning. Going to Thunderbird's Config Editor, and setting mail.server.default.fetch_by_chunks to false prevents the problem from occurring, and I get perfect attachments with the example above. I had to re-forward them though - mails that had already been downloaded could not be recovered/re-downloaded (Or at least, I don't know how to.) Obviously this is wretched MS Exchange's fault - sorry for taking your time with it. I will be making some "requests" to my college mail providers and forwarding my experience. Thanks for your time, Wes
Better a false alarm than missing a bug. Thanks fro investigating and figuring it out.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.