280185 - Attachment corrupted by ascii character 10 in text file

Status: RESOLVED DUPLICATE of bug 161806

(Thunderbird :: Message Compose Window, defect)

Description

[Martin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Thunderbird 0.9

The attached text file included UNIX style line feeds. That is ascii 10 not
preceeded by ascii 13. 
When sent and opened in the Sent folder the ascii 10's have been converted to
carrage return, line feeds - the two characters ascii 13 and ascii 10.
Attached files should not be altered in anyway.

Reproducible: Always

Steps to Reproduce:
1. Create file with text "ABC" & chr(10) & "CDE"
2. Attach to email and send


Actual Results:  
3. View file in Sent Folder and you find "ABC" & chr(13) & chr(10) & "CDE"

Expected Results:  
3. View file in Sent Folder and you find "ABC" & chr(10) & "CDE"

Comment 1

[Hiro]

wfm.
Please try by 1.0 release version. 

Mac OS X 10.3.7
Tb 1.0 Release

Comment 2

[Mike Cowperthwaite]

(In reply to comment #0)
> Attached files should not be altered in anyway.

This expectation is mistaken.  If you want the file sent without alteration, you 
need to force it to be sent as a binary file -- which, unfortunately, is not 
easy to do in Thunderbird.  (It's easier in Mozilla, which allows you to 
explicitly associate extensions with MIME types.)  See bug 244618.

Presumably the file was attached with a MIME type of text/plain -- and end-of-
line conversions are done as a matter of course for such files.  If you save the 
file on a Unix system, it should be written out with only the 0x0A ("line feed") 
character at the end of the line.

Comment 3

[Rene Rask]

I confirm this issue on windows TB 1.0.2 and linux TB 1.0.2.
Trying to send plotter files to a press facility.

TB doesn't care about your attachments. Some programmer must have decided that
if it is text/plain (or TB thinks it is) then actual content isn't important
enough to care about.
To me, that is like TB recompressing jpg images because it is already a lossy
format so it obviously isn't important. Only worse, since text/plain isn't a
lossy format.

Please ensure that attached files are treated as important content which is not
to be corrupted unless the "please corrupt files" checkbox is checked.

I haven't been able to find any bug that doesn't treat this as something else
than a bug. There is a feature request for experts to be able to select the mime
type and various suggestions for workarounds.

This is a major bug. Please set it asss Major and NEW instead of unconfirmed.

Comment 4

[OstGote!]

See bug 161806 comment 6 and bug 237118. Dupe?

Comment 5

[Mike Cowperthwaite]

I agree the first bug is a dupe; the second is about files that contain no line 
breaks at all.  See also bug 269390.

*** This bug has been marked as a duplicate of 161806 ***