Opened 13 years ago

Closed 13 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


First of all: I have read 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!


Change History (1)

comment:1 by Tim Kosse, 13 years ago

Resolution: rejected
Status: newclosed
Type: defectBug 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.

Note: See TracTickets for help on using tickets.