302760 - Additional CR/LF if text file attachment is larger than 10K

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Arne]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Thunderbird Version 1.0.6 (20050716)

When I include a .ICP file in a mail it will be corrupted. 
Thunderbird includes the file as follows:

Content-Type: text/plain;
name="CH007JP_OTHIGA165.icp"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="CH007JP_OTHIGA165.icp"

Reproducible: Always

Steps to Reproduce:
1. Write a mail
2. Attach a plain text file without CR/LF larger than 10KB
3. Send the mail.
Actual Results:  
The attachement has an addional CR/LF after exactly 10240 Bytes. Therefore the
above file cannot be read by the assigned software.

Actual Results:  
By this behaviour the files are corrupted and thus users are losing data.

Expected Results:  
Just leave the file as it is, e.g. by attaching it in BASE 64. My old Netscape
4.07 never produced this problem, and even Outlook can attach such files correctly.

Comment 1

[David :Bienvenu]

can you attach or e-mail me ([e-mail]) the .icp file? I tried this
with a plain text file and didn't see a problem.

Comment 2

[Mike Cowperthwaite]

xref bug 302314

Comment 3

[David :Bienvenu]

OK, I think this has to do with trying to send an attachment > 10K with no
linebreaks with a 7bit transfer encoding. I believe we have some code that won't
handle a line > 10K, and just breaks it up. I think we should be base64 encoding
this attachment...

Comment 4

[Mike Cowperthwaite]

See attachment 191065 [details] (incorrectly attached to bug 302314).

It does exhibit the symptom described, but the original file does not contain a 
CR/LF as reported at the other bug.

Since TB does not allow the user to define MIME types, it's difficult (but not 
impossible) to configure the program to interpret .ICP files as binary.
See bug 244618 comment 4.

Comment 5

[David :Bienvenu]

I was just suggesting if the attachment is one giant line, we could just
automatically base64 encode it. Though I suppose we'd have to go through the
whole attachment making sure any given line wasn't longer than some threshhold...

Comment 6

[Mike Cowperthwaite]

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

Comment 7

[Luciano Pacheco]

Attachment: Problem file, break the 2nd line,

I have a similar problem with this file.

When I send this file, the second line is wrap in 2 lines.

I'm in Thunderbird 1.5 (20051201) in WinXP sp2.

But the curious, I made a test, copy the 2nd line, and paste as a 3rd line. Don't occur the problem :S

Comment 8

[Mike Cowperthwaite]

This bug appears to have been fixed on the trunk; I believe it's from the fix 
at bug 269390.

That patch is only on the trunk right now but should be moved over to the 
1.8.1 branch for TB 2.0.

Comment 9

[David :Bienvenu]

you're right, thanks, Mike - I'll apply the fix(es) to the 1.8.1 branch.

Comment 10

[Mike Cowperthwaite]

OK, marking this fixed -- the patch from bug 269390 is now in on the branch as well.  TB 2.0 will be the first release with this fix in it, but nightly builds are available.