463200 - Command line attaching files with non-latin UTF-8 filenames messes up the names of the attachment. Affects desktop cooperation.

Status: RESOLVED DUPLICATE of bug 384160

(Thunderbird :: General, defect)

Description

[Antonis Tsolomitis]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092903 Mandriva/1.9.0.3-1mdv2009.0 (2009.0) Firefox/3.0.3
Build Identifier: Thunderbird version 2.0.0.17

thunderbird -compose attachment=file://<non-Latin UTF-8 filename>
creates attachment with unreadable attached files.
For example
thunderbird -compose attachment=file://αρχείο.txt
will attach the file, but its name is unreadable.

This affects seriously collaboration with other products. For example, if we edit a file with a non-latin UTF-8 name with OpenOffice and use the "Send as an Email" feature of OpenOffice, we get a thunderbird window with an unreadable attachment filename. It is not OO's mistake, since it can reproduced on the command line as above. 

Reproducible: Always

Steps to Reproduce:
1. touch αρχείο.txt (or any other non-latin utf-8 filename)
2. thunderbird -compose attachment=file://αρχείο.txt
3. (system locale is set to UTF-8 (actually el_GR.UTF-8).
Actual Results:  
Thunderbird opens the compose window with the file attached. However the filename that shows up in the attachment pane is garbled. Can not be read.

Expected Results:  
Attach the file with its correct UTF-8 name.

Dragging a Greek UTF-8 filename from nautilus to an already open compose window
works properly. The command line fails which affects collaboration with, say, OpenOffice, or other programs.

Comment 1

[rsx11m]

A similar case was seen in bug 432315, however with special characters in the attachment argument. It should be unambiguous that any character >0x007f is not a character of special meaning, but on the other hand, one may argue that anything other than an alphanumeric character should be encoded with %xx escape format. Thus, it is not clear to me if the fault is on OpenOffice's side for not unambiguously encoding the URI for the attachment, or if Thunderbird would be required to interpret those. The other issue may be the character set, which is assumed to be UTF-8 here, but would need to be unambiguous as well to ensure correct encoding (which is resolved in the mail headers by explicitly giving the encoding in the header value itself).

Comment 2

[Magnus Melin [:mkmelin]]

The issue was fixed recently on trunk. IIRC the solution was to allow attachment=/home/foo/αρχείο.txt, but require the encoding when it's a file url like attachment=file:///...

Comment 3

[rsx11m]

Correct, thanks for the hint, duping. This would still need to be resolved on OpenOffice's side then to pass the respective arguments.

Comment 4

[Antonis Tsolomitis]

Currently (2.0.017), attachment=/home/foo/αρχείο.txt does not work (produces unspecified error). So it will be available in next version?
Also, thunderbird --help, or in http://kb.mozillazine.org/Command_line_arguments_-_Thunderbird no way of specifying the encoding of the filenames is given. There are only these -UILocale and -contentLocale that do different things. So there is no solution currently? Lets forget OO. If there is a solution for the thunderbird command line, then I will file a bug report in OO site.

Comment 5

[rsx11m]

Antonis, it likely won't be fixed in the 2.0.0.x ("branch") version, where only security and stability issues are patched. Development is taking place for the upcoming 3.0 ("trunk") version. Thus, you cannot see it in 2.0.0.17 (and that patch was actually checked in after those release versions were built).

The first beta version for Thunderbird 3.0 is expected to come out by the end of this month, which should be considered "work in progress" and thus won't have release quality yet, but you can give it a try if you don't mind running into potentially unstable bugs.

And yes, OO would have to introduce an option to either encode file URIs with %xx characters or omitting the "file://" specification with the attachment argument, so this would require some bug to be filed with them (unless it exists already).