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

RESOLVED DUPLICATE of bug 262739

Status

RESOLVED DUPLICATE of bug 262739
15 years ago
10 years ago

People

(Reporter: aceman, Unassigned)

Tracking

Trunk
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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

15 years ago
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.)
(Reporter)

Comment 2

15 years ago
Created attachment 136219 [details]
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

15 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

15 years ago
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.
Product: MailNews → Core
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: stephend → attachments
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 262739
You need to log in before you can comment on or make changes to this bug.