Closed Bug 310925 Opened 19 years ago Closed 10 years ago

Attachment saving has 128 character limit on filenames

Categories

(MailNews Core :: Attachments, defect)

Product:
MailNews Core
Component:
Attachments
Version:
1.9.1 Branch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: ma33, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

Example email message with a long-filename attachment.
2.54 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.2) Gecko/20040808
Build Identifier: User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

TB truncate long filenames to 128 symbols (wrap error) instead extend to next line.

Reproducible: Always

Steps to Reproduce:
1. Create file with long filename (more then 32 symbols in russian, or more then
128 symbols ascii)
2. Send.
3. Receieve broken filename.

Actual Results:  
Content-Type: text/plain;
 name="=?KOI8-R?Q?=F4=C5=D3=D4=CF=D7=CF=C5=5F=C9=CD=D1=5F=C6=C1=CA=CC=C1=5F=C4=CC?==?KOI8-R?Q?=C9=CE=CF=CA39=D3=C9=CD=D7=CF=CC"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="=?KOI8-R?Q?=F4=C5=D3=D4=CF=D7=CF=C5=5F=C9=CD=D1=5F=C6=C1=CA=CC=C1=5F=C4=CC?==?KOI8-R?Q?=C9=CE=CF=CA39=D3=C9=CD=D7=C"



Expected Results:  
Content-Type: text/plain;
 name="=?KOI8-R?Q?=F4=C5=D3=D4=CF=D7=CF=C5=5F=C9=CD=D1=5F=C6=C1=CA=CC=C1=5F=C4=CC?==?KOI8-R?Q?=C9=CE=CF=CA39=D3=C9=CD=D7=CF=CC=CF=D7=2Etxt?="
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="=?KOI8-R?Q?=F4=C5=D3=D4=CF=D7=CF=C5=5F=C9=CD=D1=5F=C6=C1=CA=CC=C1=5F=C4=CC?==?KOI8-R?Q?=C9=CE=CF=CA39=D3=C9=CD=D7=CF=CC=CF=D7=2Etxt?="



Please fix this bug at last :-(
It's rather critical for russian and other non ascii users because short name
expand to very long with QP-encoding and overflow bound 128 symbols!
what thunderbird build are you using? Have you tried 1.5 beta 1? We support
wrapping with multiple filename param headers in 1.5
TB 1.5b2 & 1.6a1.
Filename extended to next line, but trancated again:

Content-Type: text/plain;
 name*0*=KOI8-R''%F4%C5%D3%D4%CF%D7%CF%C5_%C9%CD%D1_%C6%C1%CA%CC%C1_%C4%CC
 name*1*=%C9%CE%CF%CA_40%D3%C9%CD%D7%CF%CC%CF%D7.txt
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename*0*=KOI8-R''%F4%C5%D3%D4%CF%D7%CF%C5_%C9%CD%D1_%C6%C1%CA%CC%C1_%C4
 filename*1*=%CC%C9%CE%CF%CA_40%D3%C9%CD%D7%CF%CC%C
                                                   ^^^^^-?
I don't know how I can test this -- I can't get past the problem I see with 
bug 285073 comment 5.
TB 2.0.0.4:

Note that Content-Type: is sent as raw 8bit.  Content-Disposition is OK.

Content-Type: text/plain;
 name="Π² Ρ‡Π°Ρ‰Π°Ρ… юга ΠΆΠΈΠ» Π±Ρ‹ цитрус - Π΄Π°, Π½ΠΎ Ρ„Π°Π»ΡŒΡˆΠΈΠ²Ρ‹ΠΉ экзСмпляр -Π² Ρ‡Π°Ρ‰Π°Ρ… юга ΠΆΠΈΠ» Π±Ρ‹ цитрус - Π΄Π°, Π½ΠΎ Ρ„Π°Π»ΡŒΡˆΠΈΠ²Ρ‹ΠΉ экзСмпляр -Π² Ρ‡Π°Ρ‰Π°Ρ… юга ΠΆΠΈΠ» Π±Ρ‹ цитрус - Π΄Π°, Π½ΠΎ Ρ„Π°Π»ΡŒΡˆΠΈΠ²Ρ‹ΠΉ экзСмпляр -.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename*0*=KOI8-R''%D7%20%DE%C1%DD%C1%C8%20%C0%C7%C1%20%D6%C9%CC%20%C2%D9;
 filename*1*=%20%C3%C9%D4%D2%D5%D3%20%2D%20%C4%C1%2C%20%CE%CF%20%C6%C1%CC;
 filename*2*=%D8%DB%C9%D7%D9%CA%20%DC%CB%DA%C5%CD%D0%CC%D1%D2%20%2D%D7%20;
 filename*3*=%DE%C1%DD%C1%C8%20%C0%C7%C1%20%D6%C9%CC%20%C2%D9%20%C3%C9%D4;
 filename*4*=%D2%D5%D3%20%2D%20%C4%C1%2C%20%CE%CF%20%C6%C1%CC%D8%DB%C9%D7;
 filename*5*=%D9%CA%20%DC%CB%DA%C5%CD%D0%CC%D1%D2%20%2D%D7%20%DE%C1%DD%C1;
 filename*6*=%C8%20%C0%C7%C1%20%D6%C9%CC%20%C2%D9%20%C3%C9%D4%D2%D5%D3%20;
 filename*7*=%2D%20%C4%C1%2C%20%CE%CF%20%C6%C1%CC%D8%DB%C9%D7%D9%CA%20%DC;
 filename*8*=%CB%DA%C5%CD%D0%CC%D1%D2%20%2D%2E%74%78%74
Assignee: mscott → nobody
Status: UNCONFIRMED → NEW
Component: General → Attachments
Ever confirmed: true
Keywords: testcase
Product: Thunderbird → MailNews Core
QA Contact: general → attachments
Version: unspecified → 1.9.1 Branch
Testcase is available at https://bugzilla.mozilla.org/attachment.cgi?id=392754
From my description in bug #508609 (which includes more detail, and the current status of this bug as of 3.0b3):

This is a double-edged bug:

1. Drag-and-drop a file with a file name longer than 128 characters, and the
filename will be truncated to 128 characters (surprising, but potentially
tolerable)
2. Right-clicking and choosing "Save As..." shows the full name of the file
(from the attachment) in the filename field in the dialog, but choosing "Save"
from that dialog results in the dialog disappearing and NO file being written
to the disk


Reproducible: Always

Steps to Reproduce:
1. Send yourself a file with a long name (I will attach a suitable file with
130 characters plus .txt extension so you don't have to create one)
2a. Drag-and-drop the attachment somewhere
or
2b. Right-click the attachment and choose "Save As...", then try to save the
file somewhere
Actual Results:  
If you chose 2a above, the file is written in the correct folder with a file
name that appears to be truncated to 128 character.

If you chose 2b above, no file is written.

Expected Results:  
2a: file is written with full filename.

2b: file is written. Preferably with correct filename.

Notes: Fresh install of 3.0b3 on fresh install of Microsoft Windows Vista.

Active Add-Ons: AdBlock Plus (v1.1), EnigMail (v0.96a)
Inactive Add-Ons: DictionarySearch (not compatible with beta)

Truncation occurs with both encrypted/signed and non-encrypted/signed
messages/attachments.

I found this out because some fool sent me an attachment with a stupidly-long
file name. NTFS, FAT32, ext3, and may other FSs support 255-character
filenames. Consider increasing the attachment filename limit to 255 characters?
Or, is it possible to sniff the filename length limit from the file system
prior to writing, and warn the user that the filename is too long?
I'd like to point out that long filenames /send/ properly using tb: it's only at the saving process where the filename is truncated (or ignored, depending on your "save" strategy).

I recommend that the title of this bug be changed to "Attachment saving has 128 character limit on filenames" or something like that to reflect the actual problem; "Send broken long filenames" suggests that the files are broken when they are sent, which is not what I'm observing.
Update: I checked again and it appears that right-click-save-as /does/ result in the correct filename being saved. Sorry for the inaccurate report.
Summary: Send broken long filenames → Attachment saving has 128 character limit on filenames
Update for 3.0b4: this issue still occurs where filenames are truncated at what appears to be the 128-character mark.

Filename as specified in the message:
Content-Type: text/plain;
 name="0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="012345678901234567890123456789012345678901234567890123456789";
 filename*1="012345678901234567890123456789012345678901234567890123456789";
 filename*2="0123456789.txt"

Filename written to disk:

01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567

(no extension)

tb version:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
Just confirming that this bug still exists in tb 3.0.1rc (it does).
(In reply to Christopher Schultz from comment #11)
> Just confirming that this bug still exists in tb 3.0.1rc (it does).

Christopher, do you still see this in TB24?
Flags: needinfo?(chris)
If you do still see this bug, please upload a sample .eml file that reproduces it. I know there are some headers pasted into comments, but it's quite a bit easier for contributors to look at this if there's just a message they can import.
Using tb24.1.0, I can confirm that drag-and-drop works as expected (i.e. the whole filename is preserved). So, case #1 appears to have been fixed.

Single-clicking on the message (with an empty attachment), tb tells me that the attachment is empty and likely broken. It won't let me save it to the disk in this case. Not really a problem, I guess, but I'll re-test with a non-zero-byte file to test this case.

If I right-click, the filename is shown in the "Save" dialog, but when I click the "Save" button in the dialog, the dialog is dismissed and the file is not saved. This appears to be what I described above in comment #7 and later retracted in comment #9. I suspect some other environmental factor is contributing to the success or failure in this particular case. So it looks like case #2 is still a problem.

It's worth noting that in the intervening years since /my/ initial report, I've switched from Microsoft Windows to Mac OS X.
Flags: needinfo?(chris)
Okay, with a non-zero-byte file, single-click + choose file = file is written with the correct filename. Right-clicking, choosing "Save" option and then choosing file = file is written with the correct filename. The failure to save with right-clicking above must be due to the attachment being empty and tb not wanting to write it to the disk.

So it appears that this bug has been fixed.

The associated issue that I still think ought to be fixed is that of the right-click scenario with an empty file: if tb ultimately won't write the file, the user should get a warning that says so. Even though the attachment is zero-bytes, if tb asks me for a filename and I provide one and hit "Save", I really expect a file to be written in the directory I selected. Let me know if I should log a separate bug report for this.
I'm attaching an example message in case anyone wants to investigate.
The attachment in that message can be saved just fine for me, on linux trunk.
FWIW, I reported this bug as FIXED back in 2013.

I can re-check the zero-byte file issue again with tb 31.4.
Ok, lets close it as WFM.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: