GNOME Bugzilla – Bug 136613
native encoded file name is displayed as garbage via nfs/smb/ftp
Last modified: 2010-10-21 13:47:32 UTC
Description of Problem: The native encoded file names are garbled through nfs access. This happens only through nfs and smb. When these filea are accessed through local file path, these are displayed correctly. Steps to reproduce the problem: 1. login into ja_JP.eucJP 2. launch nautilus 3. configure nfs access 4. try to view on file through nfs access which has ja_JP.eucJP encoding file name Actual Results: Native encoded file name is garbled. Expected Results: The encoding file names which is same with system locale should be displayed correctly. How often does this happen? Every time at accessing Additional Information: I will attach a patch for suggested fix. Please review and integrate.
Created attachment 25366 [details] [review] Suggested fix for the bug. Need to add similar logic with local path
Created attachment 25763 [details] [review] This patch is also needed to save native encoding file name via nfs/smb
Changed Keywords of Gnome version to GNOME VER2.6. This happens on Gnome 2.6 head. I also added I18N keyword. Since the garbage file names are seem all the time, I changed priority and severity.
The smb part is wrong. Since 2.6.0 smb uris are always in utf8. I'm not sure G_BROKEN filenames should affect nfs: uris. And if it should, the patch isn't enough, as G_BROKEN_FILENAME is used in other places in nautilus.
marking patches needs-work as per Alex's comments.
*** Bug 92276 has been marked as a duplicate of this bug. ***
Updating title and version information, as there is no reason to suggest that this is fixed in 2.9.
This also happens with FTP. Here is a copy of my post to the bug 92276: I created a test FTP dir with some non-english filenames. Try this link: ftp://ftp.altlinux.ru/pub/people/slava/Filename_test There are 3 dummy files and one directory there. All have filenames in Russian. You need CP1251 encoding to see the first level file and directory. The directory contains two additional files. One has filename in UTF-8 and the other in cp1251. Mozilla and gftp do show them correctly (locale ru_RU.CP1251). Mozilla also has nice codepage selector that makes it possible to see any filenames. I can enter the directory and download any of the files. Nautilus only shows the UTF-8 filename and "Illegal Unicode sequence" instead of other filenames. It cannot enter the directory and cannot download files with 8-bit cp1251 names. Also see the screenshot: http://bugzilla.gnome.org/attachment.cgi?id=36502&action=view.
Thanks for setting up this test for us. I'm not able to test this though, since my distro libc doesn't support the ru_RU.CP1251 locale at all it seems. Testing using ru_RU.UTF-8 shows the garbled filenames as well, and if I use that I can't see the correct filenames in gftp either. Mozilla seems to be able to make more sense of this when I chose Cyrillic Windows-1251 as the encoding, but I'm not really sure there either since my russian is reall rusty ;-)
OK. I think that it is important to test with an 8-bit encoding. I added another file and a directory with KOI8-R name. Even antique distros supported ru_RU.KOI8-R. You can just compare the picture with screenshots. See. http://bugzilla.gnome.org/attachment.cgi?id=36516&action=view
I commented in the wrong bug again. I did try this and the locale is there this time. I do not get the right names using a CVS build from today. I used LC_ALL=ru_RU.KOI8-R but I didn't set G_BROKEN_FILENAMES, will that help?
No. It seems to have no effect.
Let me give yet another example on the topic, this time about GnomeVFS, I think. My Linux system locale is ru_RU.KOI8-R, and I'm accessing a Windows share that is seen through my Samba in UTF-8. You see, when I go to the shared folder with Nautilus, it gladly shows correct Russian names, since UTF-8 is what it likes. However, it is not so fine when I run GEdit and go to the same shared folder with 'Open file' dialog. Seems that in this case my system locale matters, since Russian names look like Unicode (right!) displayed in one-byte encoding (namely, KOI8-R). Which is unreadable, too.
The patch at bug 314538 may fix this issue.
Has this been fixed with the migration to gio/gvfs or can this still be reproduced in nautilus 2.30? If so, isn't this a gvfs problem?
Hm. Can anybody provide some input for the question raised in comment #15?
Based on the lack of feedback, I am assuming this to be not an issue anymore. Please reopen if it still is.