239192 - Attaching files from directories with '#' cuts name of attached file

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[Alexander Skwar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040326 Firefox/0.8.0+ (mmoy-O2-GL7-SSE2-crc32)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040325

When I attach a file from a directory which has a # in it's name (like
C:\foo#2), the name of the attached file is set to the directory name up to the
# sign.

Reproducible: Always
Steps to Reproduce:
1. mkdir "c:\foo#2"
2. Attach file bar.txt from this directory

Actual Results:  
The attached file is named "foo" (no ").

Expected Results:  
It should be named "bar.txt" (no ").

This bug also occurs with Mozilla Thunderbird 0.5+ (20040330) (ie. the currently
nightly).

Comment 1

[Mike Cowperthwaite]

I see this:
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040324

Confirming.  Changing OS to Win2K, altho I bet it occurs on all kinds of Windows 
and probably All.

Comment 2

[Alexander Skwar]

You're right, I'm also seeing this with

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040331

Changing Hardware/OS to All/All

Comment 3

[Hiro]

It reproduces.

Mac OS X 10.3.4
Thunderbird AVIARY_1_0_20040515_BRANCH build
version 0.7+ (20040702)

Comment 4

[Fabian Rodriguez:MagicFab]

I'v ereproduced this bug in:

Platform: PC
Operating system: Mandrake Linux 10 & Win98
Thunderbird build: version 0.7+ (20040727)

It also affects filenames, as explained in bug #243504 

Reproductible: Always

Steps to reproduce:

1. Create a text file with or without content, named "text #44.txt"
2. Create a new message window in Thunderbird, using either CTRL-M or the Write
button
3. Using the ATTACH button or dragging the file into the message composition
window, attach the "text #44.txt" file
4. Repeat the same test but using ".xls" as extension
5. When the recipient gets the file, tooltips and Save as... operations confirm
that the file name has been truncated. Message headers indicate this for the
.xls file:

Content-Type: application/msexcell;
 name="text "
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="text "

ACTUAL RESULTS:
The filename is truncated even before it's been sent or further processed. It's
still possible to send the file and its file type is recognized and stored. When
the recipient gets it, TB correctly detects its filetype but the filename part
starting at the "#" symbol is missing, including the extension.

EXPECTED RESULTS:
The filename should be preserved in its entirety.

ADDITIONAL BUILDS & PLATFORMS:
Also reproduced in Windows 2000 Pro and Mandrake Linux 10 using latest TB
release (not nightly). 

Comment 5

[OstGote!]

Another candidate which this bug blocks: Bug 251544.

Comment 6

[Jungshik Shin]

My patch in bug 263492 will fix this. 

Comment 7

[Martijn Wargers (dead)]

(In reply to comment #6)
> My patch in bug 263492 will fix this. 
Uhm, I think you mean bug 263462, right?

Comment 8

[OstGote!]

WFM now with Mozilla build 2004101904 on WinNT4. It is fixed.

Comment 9

[Andreas Kunz]

Yes, I also tested and this is fixed by jshin's patch in bug 263462.
Resolving.

Comment 10

[Alexander Skwar]

Could somebody please have a look at Bug 266629, which I just filed? It's IMO
closely related. There, I report that I'm unable to upload files starting with ~
in the name.

Comment 11

[[e-mail]]

I saw this bug in TB 1.0 on WinXP SP1:

I was composing an email and attaching the files, "\HW #3\HW #3.pdf" and "\HW
#4\HW #4.pdf".  The email would only show the name HW for both.  So I closed the
email window and renamed the files to "\HW #3\HW_3.pdf" and "\HW #4\HW_4.pdf". 
I then reattached to a new email message and it still showed HW for both files.

I thought it was bug 243504 that was the problem, and it still could be a
problem.  But this one supercedes it.

Comment 12

[WADA:World Anti-bad-Duping Agency]

Reopen according to comment #11 and reopen of Bug 243504.
This is because patch of prerequisite Bug 263462 was backed out on Thunderbird
1.0 branch.

Comment 13

[OstGote!]

WFM with Mozilla 1.8b build 2005011308 on WinNT4.

Comment 14

[WADA:World Anti-bad-Duping Agency]

Regression(Bug 274264) was resolved and patch of Bug 263462 was applied again.
Change back to FIXED according to FIXED again of Bug 243504.

Comment 15

[Mike Cowperthwaite]

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