After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 308238 - REMOTE_CHARSET is applied to filenames on local side
REMOTE_CHARSET is applied to filenames on local side
Status: RESOLVED FIXED
Product: gftp
Classification: Other
Component: general
2.0.18
Other Linux
: Normal normal
: ---
Assigned To: Brian Masney
Brian Masney
Depends on:
Blocks:
 
 
Reported: 2005-06-19 00:28 UTC by Ilya Evseev
Modified: 2008-11-16 17:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Ilya Evseev 2005-06-19 00:28:35 UTC 
1. Select ru_RU.KOI8-R locale on local side.
2. Create any filename in russian charset.
3. Start gFTP and look, connect to any russian FTP site hosted on Windows:
local filenames are displayed correctly, but remote filenames are corrupted.
4. Press Ctrl+O, assign remote charset to windows-1251.
5. Now gFTP displays remote filenames correctly, but local filenames are 
corrupted.
6. When gFTP copies files from Windows site to localhost, filenames are 
corrupted (still Win1251-encoded instead of KOI8-R).
Comment 1 chryse 2006-10-26 12:40:54 UTC 
I confirm this bug. There is a bug <a href=http://bugzilla.gnome.org/show_bug.cgi?id=156371>#156371</a> which is in direct dependency with this one. If one of those will be fixed, then another one also will be fixed. This is as far as I can see it.
Comment 2 Brian Masney 2006-11-03 03:32:34 UTC 
Hi,
    This is fixed in CVS. I created a tarball at http://www.gftp.org/gftp-test.tar.bz2 that has the latest code from CVS. Please let me know either way if this works. It is fixed for the local, FTP, FTPS and SSH protocols. It is not fixed in the HTTP, HTTPS and FSP protocols. I will fix those whenever I get confirmation that the other protocols are working properly.

Brian
Comment 3 André Klapper 2008-11-16 17:58:27 UTC 
fixed as per last comment