Closed Bug 287209 Opened 19 years ago Closed 17 years ago

Can't open attachment when file name contains international characters

Categories

(Thunderbird :: Message Compose Window, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 332110

People

(Reporter: admin, Assigned: mscott)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050321 Firefox/1.0+
Build Identifier: Thuderbird 1.0+ (2005-feb-23)

when try to send mail wich attachment who have international characters in file
name 
getting error  that file is missing 

Reproducible: Always
please provide a proper bug report

you chose OS: WinXP but you reported under Linux, which one is it?
can you give us an example of a filename with international characters in it
that caused the bug?
when exactly do you get the error? is there an error message?
please provide steps to reproduce the bug
How to reproduce:
1. use the message below. 
2. try to save the attachments. They contain japanese characters. 
3. When saving, the japanese characters are converted to underscores.

From: dummy@dummy.com 
To: dummy@dummy.com
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_-g2kB7fZp5Tm1qbi6dss92"

--=_-g2kB7fZp5Tm1qbi6dss92
Content-Type: text/xml; name="=?UTF-8?B?44GC44GE44GG44GI44GKY21kX2FyZy54bWw=?="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="=?UTF-8?B?44GC44GE44GG44GI44GKY21kX2FyZy54bWw=?="

--=_-g2kB7fZp5Tm1qbi6dss92
Content-Type: application/octet-stream;
name="=?UTF-8?B?44GC44GE44GG44GI44GKN2J5dGVz?= =?UTF-8?B?Lmlu?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="=?UTF-8?B?44GC44GE44GG44GI44GKN2J5dGVzLmlu?="

/9j/4AAQSg==

--=_-g2kB7fZp5Tm1qbi6dss92
um, i forgot to mention that you need to do this on windows NT/2000/XP which has
unicode filename support. and, you need an NTFS filing system. Also, you should
install japanese support. winXP is the only OS i have been able to test on.
(In reply to comment #3)
> um, i forgot to mention that you need to do this on windows NT/2000/XP which has
> unicode filename support. and, you need an NTFS filing system. Also, you should
> install japanese support. winXP is the only OS i have been able to test on.

I can confirm this. Files names written with some characters with Latin2
(CP1250) or Cyrillic (CP1251) code pages cannot be sent. Also, the file names
are represented in the Attachments window without these characters, with
approximation in case of CP1250 (šdccžŠĐCCŽ) and with ____ for Cyrillic
character. The error message is:

  Sending of message failed.

  Unable to open the temporary file C:\path\to\the\file\šdccžŠĐCCŽ.txt. Check
your 'Temporary Directory' settings.

I assume the error is self explaining.

OS: MS Windows XP Proffessional, Service Pack 2
Mozilla Thunderbird: version 1.0.2 (20050317)
In my case (TB 1.02 English on WinXP Japanese), I can attach and send files with
Japanese names with no problems whatsoever.

However, if I try attaching a file whose name is in Thai or Korean, I see two
different problems depending on how I attach the file. 

(1) If I open a new Compose window, click on the Attach button and select the
file, it will appear in the attachments box but with the characters all replaced
by underlines. If I try to send the file, I get an error message "Sending of
message failed. Unable to open temporary file <path/name>. Check your 'Temporary
Directory' setting."

(2) If I open a new Compose window and drag the file into it, the attachment
icon shows up in the attachments box, but there's no filename whatsoever, not
even underlines. If I try to send it, I get the same error message.

Some other people in the forums are reporting the same problem. See
http://forums.mozillazine.org/viewtopic.php?t=287965
In addition to https://bugzilla.mozilla.org/show_bug.cgi?id=287209#c5 :
I can confirm that the same problem occurs with Chinese under W2K.
Seeing the same here with at least two different webmail solutions (Critical 
Path and Hula) If I create a word document with norwegian characters in the 
filename and send it to myself Firefox won't see that as a Word document when I 
try to open it and gives a dialog to choose which application should handle 
this document. If I save the document it uses some strange name for the 
attachment that is conjured up by the webmail solution AFAICS.
Forgot to mention that I see this on Fedora Core 4 and Windows XP professional 
using firefox 1.0.6.
Sorry for the spam, forgot to add myself to Cc:
Brain not functioning at all this morning it seems. Ignore my three comments as 
they are related to using Firefox against a webmail solution and has nothing to 
do with this bugreport :-|
I'm seeing a similar problem using Thunderbird 1.5b1 on Linux: after detaching
attachments to a directory containing Swedish characters, Thunderbird cannot
open any of the saved attachements - instead it says something like:

"The file /tmp/ההה/image_00014.jpg cannot be found. Please check the location
and try again."

Using a file system browser I can confirm that the path is correct, so
Thunderbird is most likely confused by something in the filename. Detaching the
same attachments to another directory with an plain ASCII-composed name doesn't
give the same problem.

Confirming the bug, hoping it will be fixed before the 1.5 release.

Using Thunderbird version 1.5 Beta 1 (20050908).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Summary: Can't open attachment then file name contains international characters → Can't open attachment when file name contains international characters
(In reply to comment #11)
> I'm seeing a similar problem using Thunderbird 1.5b1 on Linux: after detaching
> attachments to a directory containing Swedish characters, Thunderbird cannot
> open any of the saved attachements - instead it says something like:
> 
> "The file /tmp/���/image_00014.jpg cannot be found. Please check the location
> and try again."
> 
> Using a file system browser I can confirm that the path is correct, so
> Thunderbird is most likely confused by something in the filename. Detaching the
> same attachments to another directory with an plain ASCII-composed name doesn't
> give the same problem.
> 
> Confirming the bug, hoping it will be fixed before the 1.5 release.
> 
> Using Thunderbird version 1.5 Beta 1 (20050908).


I can confirm a similar problem with  Thunderbird 
(version 1.5 (20051201), running on Win XP pro, SP2, Athlon1700, 756MB RAM)

attachments if international characters from Latvian language (ISO 8859-13 character set) are used in the path to the folder where the file-to-be-attached resides. 
Steps to reproduce the bug:
1) create a folder in  "My Documents" folder, using folder name with international (Latvian)characters, for example:   

C:\Documents and Settings\user\My Documents\Mēģinājums\

2) create any file in that folder and name it using any short ASCII name, for example:
 C:\Documents and Settings\user\My Documents\Mēģinājums\testdocument.txt

3) Attach it to Thunderbird message using drag  and drop. So far everything goes OK
4) On attempt to send the file, Thunderbird produces error message.
5) Rename the folder, using only ASCII characters, reattach the file, everything works OK.

The error is reproducible on any XP-Pro SP2 computer which I tested. 
Confirming with XP SP2, Thunderbird 1.5.0.9.
Sending attached file with polish character ń in name fails with "Unable to open temporary file...".
Also file shows up with "n" instead of "ń" in attached files list.
I confirm this error too with XP SP2, Sea Monkey 1.1, czech localisation. I think it concerns even space in the filename, the space in the filename is shown on the error message by %20. The error which is connected with that is, that it gives an error, that the message could not be saved to draft directory with similar error results showing that strange Temp directory message.
Is somebody working on that?
QA Contact: message-compose
This is a duplicate of the bug https://bugzilla.mozilla.org/show_bug.cgi?id=332110
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.