gvfs ftp backend has no mean to specify encoding for remote filenames
Submitted by Andrew Zabolotny
Assigned to gvf..@..e.bugs
Link to original bug (#554558)
Description
Please describe the problem: The FTP protocol is somewhat a mess because in older times the filename encoding was not standardized in any way. This has lead to lots of ftp servers which use different filename encodings for characters > 128. Most large public ftp sites don't play with this and just use latin1 characters, but in local networks there are thousands of user ftp sites who don't care about RFCs and such.
AFAIR there's a recent FTP RFC which introduces the notion of filename encoding; however there are still little servers using it, and most users have to deal with existing ftp servers, which don't support this. Even if they would, I'm not sure GVFS supports this as well, but anyway this is not the point.
Most ftp clients have a special setting which defines the encoding of filenames on the remote server. This is usually a per-server setting, however sometimes there's a default value which is useful as well.
It would be very useful to have such a option in GVFS as well. Without it the ftp backend is mostly useless for users in countries using characters with codes > 128 for file names.
Steps to reproduce:
- Install vsftpd (for example, any other ftp server will do) and start it
- Unpack the attached tarball to ~ftp. This should create a couple of directories and empty files under pub/ using windows-1251 encoding.
- Open the ftp server via nautilus.
Actual results: Directory and file names using characters > 127 will be undreadable
Expected results: Should be readable
Does this happen every time?
Other information: As I see it, a global setting could be stored somewhere in gconf and a per-server encoding could be either as part of URL (e.g. ftp://user:password@encoding*localhost/pub or something like that) or asked in a dialog, just like login information is.
Version: 0.2.x