Копирование файлов с русскими именами с помощью nautilus с использованием схемы smb:// создаёт файлы с испорченными именами, судя по всему, в unicode. Различные вариации настроек кодировки в ~/.smb/smb.conf успеха не принесли. Копирование с примонтированных smbmount ресурсов таких же файлов с помощью /bin/cp даёт правильные имена файлов. nautilus2-2.6.3-alt1 gnome-vfs2-2.6.1.1-alt1.1 gnome-full-sisyphus-2.6.0-alt1
Да, на ФС с именами в юникоде все нормально. 2ab@ Александр, может что подскажете хотя бы в общем и целом? На что должна смотреть gnome-vfs, если имена файлов не в юникод?
На unix charset в smb.conf, очевидно. Если этой опции в конфигурационном файле нет, то она по умолчанию равна UTF8.
Виталий, попробуй сделать ln -s /etc/samba/smb.conf ~/.smb/smb.conf
Сделал. Копирование работает странно: Файл МАШИНА.mp3 скопировался с правильным именем. Файлы вида Машина времени - Синяя птица.mp3 копируются с именами кашей. Кстати, в адресной строке русские символы кодируются как 0%B5%D0 nautilus2-2.6.3-alt1 samba-client-3.0.3-alt1.1 gnome-full-sisyphus-2.6.0-alt1
А "unix charset" в /etc/samba/smb.conf выставлен в кодировку твоей локали? Если не трудно, протестируй на smb:// утилиты из $ rpm -ql gnome-vfs2-utils /usr/bin/gnomevfs-cat /usr/bin/gnomevfs-copy /usr/bin/gnomevfs-info /usr/bin/gnomevfs-ls /usr/bin/gnomevfs-mkdir
Да, unix charset = CP1251 - это правильно, у меня локаль ru_RU.CP1251, она же системная. gnomevfs-ls smb://pserver/old/mp3/ , запущенный из терминала, выдаёт вместо русских имён знаки вопроса. Кстати, ещё пример копирования в nautilus: 01 - Инспектор по....mp3 ok 02 - Гномы-каннибалы.mp3 каша samba-client-3.0.3-alt1.1 nautilus2-2.6.3-alt2 gnome-vfs2-utils-2.6.1.1-alt1.3
Виталий, попробуй с новыми glib2-2.4.4-alt1.1 gnome-vfs2-2.6.1.1-alt1.4 Пока эти пакеты есть только в ftp://ftp.altlinux.ru/pub/people/aris/.
Без изменений, всё так же. nautilus2 копирует в имя с кашей, gnomevfs-ls выводит русский в utf-8 вместо текущей локали. gnome-vfs2-utils-2.6.1.1-alt1.4 glib2-2.4.5-alt1 gnome-vfs2-2.6.1.1-alt1.4
А сейчас? (сорри, самому проверить не на чем)
Да, это теперь мой баг.
Мне сейчас тоже проверить пока не на чем.
А сейчас?
Андрюш, получается проверить?
gnome-vfs устарел, вместо него теперь gvfs. Прошу подтвердить на современном Сизифе и, соответственно, при установленном gvfs-backends-smb.
Мне сейчас проверить не на чем. Как аврал спадёт, попробую проверить.
Аврал спал? :)
$ nautilus nautilus: symbol lookup error: /usr/lib64/gio/modules/libgiohal-volume-monitor.so: undefined symbol: dbus_watch_get_unix_fd gvfs-backend-smb-0.99.1-alt1 nautilus-2.22.5.1-alt1 dbus-1.0.2-alt4 hal-0.5.10-alt6 udev-108-alt2 Обновил dbus: nautilus: symbol lookup error: /usr/lib64/gio/modules/libgiohal-volume-monitor.so: undefined symbol: libhal_get_all_devices_with_properties Обновил hal - nautilus запустился. В меню Вид стоит галка возле "Показывать адресную строку", однако полей ввода никаких нет. В пунктах слева ничего про сеть нет: Места /home Рабочий стол Файловая система Корзина Запускал в сеансе под xfce, сейчас попробую новым пользователем под Gnome. Система - несвежий Сизиф
Виталий, сделай, пожалуйста себе свежий сизиф или попробуй с livecd: ftp://ftp.altlinux.org/pub/beta/desktop/20080822/altlinux-4.1.0-beta-20080822-gnome-i586-ru-livecd.iso
Да, получить рабочий Gnome оказалось для меня непосильной задачей. gnome-full не устанавливается из-за gnome-default. Точечные установки не проходят из-за неполных зависимостей, постоянно ошибки вида /usr/bin/gnome-session: symbol lookup error: /usr/bin/gnome-session: undefined symbol: gnome_keyring_daemon_prepare_environment_sync Когда это всё победил, не заработал логин из gdm в сессию Gnome под новым пользователем - что-то про exec line. Работает сессия Gnome failsafe, там наутилус запускается, но про сеть слева по прежнему ничего. Свежий сизиф я себе сделал на работе и результат крайне не понравился - дома я пока такое не рискну. А samba, к сожалению, поднята именно дома. Короче, поставил livecd на закачку.
В этом livecd файлы видны и копируются нормально. Оказывается, сеть доступна в наутилусе через меню "Переход". Попробовал на своей машине с локалью CP1251 - та же ошибка: 01 - Инспектор по....mp3 OK 02 - Гномы-каннибалы.mp3 Каша (02 - Гномы-каннибалы.mp3) МАШИНА.mp3 OK Машина времени - Синяя птица.mp3 Каша (Машина времени - РЎРёРЅСЏСЏ птица.mp3) Кстати, замечания по livecd: В заставке написано Altlinux 4.0 вместо 4.1 Ругань при монтировании /proc и /sys (похоже на забытый mtab) Зачем-то пытается стартовать openvpn Так сразу непонятно, что пользователя зовут altlinux Из меню Gnome не запускается xterm и второй терминал с похожим названием.
Юрий, а можно сделать для эксперимента такой же livecd, только с локалью ru_RU.CP1251 ? Чтобы убедиться, что бага не в версиях моего софта, а действительно в перекодировке.
(In reply to comment #21) > Юрий, а можно сделать для эксперимента такой же livecd, только с локалью ru_RU.CP1251 > ? Чтобы убедиться, что бага не в версиях моего софта, а действительно в > перекодировке. > Виталий, ситуация с не-utf-локалями безнадежная, -- ошибки при открытии, сохранении файлов есть во многих приложениях, единолично с ними бороться я не смог и перешел с кои-8р на юникод, что и тебе рекомендую.
(In reply to comment #21) > Юрий, а можно сделать для эксперимента такой же livecd, > только с локалью ru_RU.CP1251? Чудак-человек, LC_ALL=ru_RU.CP1251 LANG=ru_RU.CP1251 nautilus не быстрее ли? :) А gtk2 и gnome2 в области восьмибитки -- действительно, такие же кастраты, как и делавшие это архитектурное лишение :-(
Я бы не был столь злобным. Для начала, все приложения на основе GLib умеют корректно работать с разными кодировками в именах файлов: http://library.gnome.org/devel/glib/unstable/glib-running.html Можно попробовать и G_FILENAME_ENCODING, и G_BROKEN_FILENAMES. Для начала, я бы попробовал G_FILENAME_ENCODING=@locale
(In reply to comment #24) > Я бы не был столь злобным. Для начала, все приложения на основе GLib умеют > корректно работать с разными кодировками в именах файлов: > http://library.gnome.org/devel/glib/unstable/glib-running.html > > Можно попробовать и G_FILENAME_ENCODING, и G_BROKEN_FILENAMES. Для начала, я бы попробовал > G_FILENAME_ENCODING=@locale Не поможет. $ cat /etc/profile.d/libglib2.sh ## This causes GLib2 applications to convert filenames from ## locale encoding to UTF-8. If the locale encoding is already ## UTF-8 then it makes no difference. export G_BROKEN_FILENAMES=1 # This causes GLib2 applications to convert filenames from # G_FILENAME_ENCODING encoding to UTF-8. # Any application can use G_FILENAME_ENCODING for this purposes # or link natspec library NATSPEC=/usr/bin/natspec test -x $NATSPEC && export G_FILENAME_ENCODING=`natspec -f`
(In reply to comment #23) > (In reply to comment #21) > > Юрий, а можно сделать для эксперимента такой же livecd, > > только с локалью ru_RU.CP1251? > Чудак-человек, LC_ALL=ru_RU.CP1251 LANG=ru_RU.CP1251 nautilus не быстрее ли? :) В livecd nautilus уже запущен, и после kill pid запускается без учёта моего LANG. Впрочем, путём хака /etc/init.d/livecd-setlocale я выставил локаль ru_RU.CP1251, и каша с некоторыми именами воспроизвелась. Интересно то, кто каша с именами видна только при обращении nautilus через smb, при просмотре этих файлов на локальной fs всё нормально (локаль ru_RU.CP1251). > > А gtk2 и gnome2 в области восьмибитки -- действительно, такие же кастраты, как и > делавшие это архитектурное лишение :-( >
(In reply to comment #22) > (In reply to comment #21) > > Юрий, а можно сделать для эксперимента такой же livecd, только с локалью ru_RU.CP1251 > > ? Чтобы убедиться, что бага не в версиях моего софта, а действительно в > > перекодировке. > > > > Виталий, ситуация с не-utf-локалями безнадежная, -- ошибки при открытии, > сохранении файлов есть во многих приложениях, единолично с ними бороться я > не смог и перешел с кои-8р на юникод, что и тебе рекомендую. Ну зачем же единолично :) Можно собрать testcase и озадачить авторов. Почему-то мне кажется, что дело всё-таки не в локалях, а невоспроизводимость в UTF-8 - просто совпадение. Но если мантейнеры решат, что Gnome уже 4 года как Unicode-only, я не буду против :)
Ещё кстати про этот livecd: 1. Терминал теперь запускается, почему не запускался при первой загрузке - непонятно. 2. Наличие локалей не *.UTF-8 на диске удивило - их без хака livecd-setlocale использовать невозможно, только место занимают.
(In reply to comment #27) <skip> > > Ну зачем же единолично :) Можно собрать testcase и озадачить авторов. Почему-то > мне кажется, что дело всё-таки не в локалях, а невоспроизводимость в UTF-8 - > просто совпадение. Не, не совпадение. aMule, еpiphany, gthumb, например, что-то еще, уже не помню, на что натыкался. > Но если мантейнеры решат, что Gnome уже 4 года как Unicode-only, я не буду против :) Ну, мантейнер Open Office уже давно просто посылает куда-подальше не-utf пользователей. А мы еще разговоры ведем пятый год :)
(In reply to comment #24) > Я бы не был столь злобным. Ну как тебе сказать. Когда фиксил, скажем, file-roller, поглядывая в патчи lav@ и его же http://www.freesource.info/wiki/Lokalizacija/LokalizacijaProgramm&#h323-5 -- выражения в сторону семибитных существ были сильно менее мягкими. (In reply to comment #27) > Но если мантейнеры решат, что Gnome уже 4 года как Unicode-only, > я не буду против :) Майнтейнеры как раз иногда исправляют, а багу надо вешать всё-таки на ДНК апстрима, как бы ни избегал подобных формулировок. Юникод -- это наше светлое будущее, привыкай.
Ну раз Миша велел привыкать, можете закрывать багу :) Так сложилось, что я уже не пользуюсь Gnome и samba.
Закрываю.
