file-roller-2.26.2-alt1 glib2-2.22.2-alt1 libgio-2.22.2-alt1 libgtk+2-2.16.6-alt1 libnautilus-2.22.3-alt2 file-roller can't access a file with Russian name (at least, when working in ru_RU.CP1251). How to reproduce: $ locale LANG=ru_RU.CP1251 LC_CTYPE="ru_RU.CP1251" LC_NUMERIC="ru_RU.CP1251" LC_TIME="ru_RU.CP1251" LC_COLLATE="ru_RU.CP1251" LC_MONETARY="ru_RU.CP1251" LC_MESSAGES="ru_RU.CP1251" LC_PAPER="ru_RU.CP1251" LC_NAME="ru_RU.CP1251" LC_ADDRESS="ru_RU.CP1251" LC_TELEPHONE="ru_RU.CP1251" LC_MEASUREMENT="ru_RU.CP1251" LC_IDENTIFICATION="ru_RU.CP1251" LC_ALL= $ touch a $ zip a.zip a adding: a (stored 0%) $ file-roller a.zip # Ok. $ zip имя.zip a adding: a (stored 0%) $ file-roller имя.zip It shows an error message: "Не удалось открыть «имя.zip» Файл не существует" Workaround: Use "unzip". Also, selecting the file through the "Open" dialog in file-roller works (but the filename is not correctly displayed in the title of the window then--it is displayed as three framed Xs).
Details: $ strace -e trace=file file-roller имя.zip 2>&1 | fgrep .zip execve("/usr/bin/file-roller", ["file-roller", "\350\354\377.zip"], [/* 63 vars */]) = 0 lstat64("/home/mama/tech-problems/zip-Russian/\320\270\320\274\321\217.zip", 0xbff35130) = -1 ENOENT (No such file or directory) $
+1 workaround: use xarchiver-0.5.2-alt1.
So neither archive manager with GUI (file-roller or xarchiver) is working well with Russian filenames: cf. https://bugzilla.altlinux.org/show_bug.cgi?id=22463 -- either the problem is with a Russian name of an included file, or with a Russian name of the archive file. :(
(In reply to comment #3) > So neither archive manager with GUI (file-roller or xarchiver) is working well > with Russian filenames: cf. https://bugzilla.altlinux.org/show_bug.cgi?id=22463 > -- either the problem is with a Russian name of an included file, or with a > Russian name of the archive file. :( Workaround: /usr/lib/kde4/bin/ark from kde4utils-ark-4.3.3-alt0.M51.1 works fine in this situation.
I'm afraid gtk/gnome folks just can't imagine 8-bit locales... I've patched file-roller a few years ago (before unzip was patched to cope with charsets), but please clarify: is it feasible for you to follow the masses and migrate to UTF-8 (which I started for new systems but didn't do for existing ones yet myself), *or* should I try and dig it up, update and apply to the package? [moving to Sisyphus as that's where the bug might be fixed before copying/backporting the package]
BTW I've partially fixed this a while ago for a customer, patches were posted. *** This bug has been marked as a duplicate of bug 10851 ***
