226080 - A message saved as TXT with attachments named with full path and 8-bit characters produces 0 byte file

Status: RESOLVED DUPLICATE of bug 262739

(MailNews Core :: Attachments, defect)

Description

[:aceman]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.5) Gecko/20031007

Saving specific messages is broken in the following way:

Reproducible: Always

Steps to Reproduce:
1. Get a message containing attachments which have the full path to the original
file specified (in the MIME header) - some strange mailers (like webmails) do
this. OE and Mozilla do not.
2. The path should also contain 8-bit (accented characters)
3. Save the message as TXT (plain text)

Actual Results:  
The resulting file is empty.

Expected Results:  
The file should be saved correctly, as it is done using the other export formats
(html, eml).

Comment 1

[Mike Cowperthwaite]

Reporter (aceman): could you please attach a sample message, in .EML format, to 
this bug so we could verify?  (A relatively small message if possible.)

Comment 2

[:aceman]

Attachment: Raw message showing the problem.

This is an example message. It was stripped from a real message. I removed
unnecessary (personal) headers and cut the attachments so that they are
undecodable. But it still shows the bug. Atleast for me.

Comment 3

[Mike Cowperthwaite]

I can confirm this behavior; replicated with
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031120

The expected result (from the attached sample) is a file that contains something 
like:
=====begin paste=====
Subject: none
Attachment
From:
censored
Date:
Tue, 11 Nov 2003 19:08:23 +0100
To:
censored

text


C:\\WINDOWS.000\\Pracovná plocha\\mail.rar
	
Content-Type:
	APPLICATION/octet-stream
Content-Encoding:
	BASE64

[etc...]
=====end paste=====
If the sample email is edited to replace the á's with a's, the mail is saved as 
expected.

Note that Mozilla (at least sometimes) encodes attachment names with hi-ANSI 
characters like this:
   Content-Type: image/png; name="=?ISO-8859-1?Q?fact=F6id=2Epng?="
The lack of this encoding (expectation of 7-bit characters in the headers) may 
be the root cause of the problem.  On the other hand, this particular email has 
a top-level ISO-8859-2 encoding.


For reference, see bug 192901, but this is quite a different behavior here.

Comment 4

[:aceman]

Thanks for confirmation.

I don't see the behaviour in  bug 192901. Actually, it works really well here
(in 1.5), it correctly offers the file name for the attachment (with accented
chars preserved). But of course, it may may work because of the coincidence,
that e.g. 'á' is in the same position in iso-8859-2 and win-1250. But it even
replaced dangerous characters - '\' is replaced with '-'. Maybe that function
could be used to parse the attachment names when saving the message text.

Comment 5

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 6

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"