User-Agent: Opera/9.00 (Windows NT 5.1; U; en) Build Identifier: Thunderbird 1.5 (20051201) I received a mail from POP3 (local storage), with 17 files attached. - If I choose 'Save All' only 14 are saved - I can't view the file when opening it from thunderbird - All 17 files are listed in attachment - As they're ASCII files, they're displaying below mail content, but only 14. Reproducible: Always Steps to Reproduce: 1.Open Thunderbird 2.Select the mail 3.Double click on an attachment to view it Actual Results: Nothing Expected Results: Being able to view the file
If it helps, all 3 files are empty. As the sender did use Thunderbird (same version), I think it's an inconsistency. It should - Refuse to send an empty file or - Accept to send an empty file (actuel behaviour) - Open/Save an empty file from receiver end
(In reply to comment #1) > If it helps, all 3 files are empty. As the sender did use Thunderbird (same > version), I think it's an inconsistency. It should > [...] > - Open/Save an empty file from receiver end It should, in fact, allow an empty file to be saved. Please save the message with the attachments as a .EML file and attach that to this bug, using the Create New Attachment link above.
Here's an email reproducing the bug. Basically all you have to do is send you a mail with an empty file as attachment.
->new using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060221 Thunderbird/1.5 ID:2006022107
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Summary: Unable to save or view attachment → Unable to save or view attachment for empty files
Attachment #212862 - Attachment mime type: application/octet-stream → message/rfc822
Reproduced: TB 1.5, TB 1.6a1-0216, Seamonkey 1.0 Works correctly with TB 1.0, Moz 1.7.12 Note that if a file by the same name exists, you will be prompted for "Do you want to overwrite?" but no overwrite occurs.
Component: Mail Window Front End → MailNews: Attachments
Product: Thunderbird → Core
Version: unspecified → 1.8 Branch
in the case of an empty file, onStartRequest never gets called so we never create the output stream. The act of creating the output stream causes the file to get created. I moved this into the constructor for the save message listener and out of OnStartRequest so it happens even if we never receive an OnStartRequest. I believe removing the Cancel / alert code in the case where we fail to open a stream is going to be safe (and a very unusual occurrence anyway).
Attachment #222407 - Flags: superreview?(bienvenu)
Comment on attachment 222407 [details] [diff] [review] the fix Do you *need* to remove the alert/cancelled code? Couldn't you change the test to if (!m_outputStream) instead of if (NS_FAILED(rv)) because we create the m_outputStream in the constructor now?
Attachment #222407 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 222407 [details] [diff] [review] the fix good idea David, new patch coming up.
Attachment #222407 - Attachment is obsolete: true
This preserves the Alert/cancel code.
Attachment #222693 - Flags: superreview?(bienvenu)
Comment on attachment 222693 [details] [diff] [review] better fix the one case this won't handle is a case that didn't work before anyway - save as failing for an empty file when it couldn't create the output stream.
Attachment #222693 - Flags: superreview?(bienvenu) → superreview+
Attachment #222693 - Flags: approval-branch-1.8.1?(mscott)
fixed on the trunk. The branch is closed at the moment.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Attachment #222693 - Flags: approval-branch-1.8.1?(mscott) → approval-branch-1.8.1+
V with TB 2a1-0601, Win2K.
Status: RESOLVED → VERIFIED
*** Bug 351037 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.