Opened 15 years ago
Closed 15 years ago
#4881 closed Bug report (rejected)
Downloading failes, not renaming - charset issue (iso-8859-1)
Reported by: | Hans F. Nordhaug | Owned by: | |
---|---|---|---|
Priority: | high | Component: | FileZilla Client |
Keywords: | charset, encoding, utf-8 | Cc: | |
Component version: | Operating system type: | Windows | |
Operating system version: | XP Professional SP3 |
Description
First of all: I have read http://wiki.filezilla-project.org/Character_Set and you could reject this request simply based on the fact that UTF-8 isn't used. However, please read on.
The problem is that renaming works, but downloading fails. I would have understood if both failed. This inconsistent behavior seems strange and is a bug in my view.
The server is a CentOS 4.7 with OpenSSH 3.9p1. It's using iso-8859-1 as default charset. When FileZilla connects, it deactivates UTF-8 (because the output of the ls command contains illegal characters I guess - a test file named "æøå.txt"). When I try to download the file "æøå.txt", it fails:
Command: get "æøå.txt" "C:\Documents and Settings\Hans\Desktop\æøå.txt" Error: /home/hans/æøå.txt: open for read: no such file or directory
However, renaming works:
Command: mv "æøå.txt" "æøa.txt" Status: /home/hans/æøå.txt -> /home/hans/æøa.txt
It's probably my lack of knowledge when it comes to the SFTP protocol, that makes this behavior weird to me.
Thanks for your time and effort - FileZilla is great!
Regards,
Hans
Change History (1)
comment:1 by , 15 years ago
Resolution: | → rejected |
---|---|
Status: | new → closed |
Type: | defect → Bug report |
Depending on the command used, the fzsftp asks the server to canonify the path/filename combination.
The primary difference is that in the case of mv the source doesn't get canonified. If anything one could argue that not canonifying the source filename is a bug.
In any case, using some random character set other than UTF-8 is the true problem. The behavior if using any other character set is just undefined.