328027 - Unable to save or view attachment for empty files

Status: VERIFIED FIXED

(MailNews Core :: Attachments, defect)

Description

[Boris Herbinière-Sève]

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

Comment 1

[Boris Herbinière-Sève]

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

Comment 2

[Mike Cowperthwaite]

(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.

Comment 3

[Boris Herbinière-Sève]

Attachment: Mail showcasing the problem

Here's an email reproducing the bug. Basically all you have to do is send you a mail with an empty file as attachment.

Comment 4

[Magnus Melin [:mkmelin]]

->new using
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060221 Thunderbird/1.5 ID:2006022107

Comment 5

[Mike Cowperthwaite]

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.

Comment 6

[Scott MacGregor]

Attachment: the fix

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).

Comment 7

[David :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?

Comment 8

[Scott MacGregor]

Comment on attachment 222407 [details] [diff] [review]
the fix

good idea David, new patch coming up.

Comment 9

[Scott MacGregor]

Attachment: better fix

This preserves the Alert/cancel code.

Comment 10

[David :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.

Comment 11

[Scott MacGregor]

fixed on the trunk. The branch is closed at the moment.

Comment 12

[Mike Cowperthwaite]

V with TB 2a1-0601, Win2K.

Comment 13

[Mike Cowperthwaite]

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