ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | неверные опции монтирования (codepage,iocharset) для vfat | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Eugene Vlasov <eugvv> |
| Component: | hal | Assignee: | Nobody's working on this, feel free to take it <nobody> |
| Status: | CLOSED WORKSFORME | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P2 | CC: | eostapets, genix, lav |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
|
Description
Eugene Vlasov
2005-02-11 23:05:09 MSK
s/fvat/vfat Это сильно зависит от кодировки. Пока непонятно, как выставлять правильную. hal сейчас не выставляет никаких параметров, связанных с кодировками. Это как это не выставляет? Проблема, как я вижу, на месте:
$ grep charset /etc/hal/fdi/policy/01-charset.fdi
<merge key="volume.policy.mount_option.iocharset"
type="string">utf8</merge>
$ rpm -qf /etc/hal/fdi/policy/01-charset.fdi
hal-0.5.4-alt6
Кодировку должен выставлять кто-то другой. Например ivman. Тогда зачем прибито такое умолчание в /etc/hal/fdi/policy/01-charset.fdi ? Стоп, а при чем тут ivman? Без определенных теложвижений его никто и запустить не в состоянии со стандартными правилами hal... Значит нужно что бы мог. Во всяком случае mainstream на любые телодвижения на тему кодировок посылает именно в hal/pmount. Это значит мне нужно таскать за собой кучу правил hal, которые будут перекрывать то, что идет в коробке? Я не согласен - я попадаю в ситуацию догоняющего, а учитывая нечеловеческий интелект, необходимый для создания правил, перекрывающих сже существующие... Оторви правила, касающиеся монтирование в отдельный пакет типа hal-automount-rules, я поставлю на него конфликт. Другого выхода я не вижу... правила для автомонтирования как раз вырваны в отдельный пакет. В общем идею я понял - правила для кодировок перенесу в submount. Может имеет смысл также в post-install править устанавливаемые общесистемные правила на основе /etc/i18n ? наверное не стоит. если посмотреть внимательно - для utf-8 нет привязки к русскому языку. Соответственно можно считать что оно практически универсально. Ну так пользователи utf-8 и не испытывают особого дискомфорта от этой опции... Но учитывая положение дел с самим utf-8 мне кажется что мазохистов, подобных мне, найдется немного и у 99% будет таки стоять koi8-r или cp1251 в /etc/sysconfig/i18n Ситуация с кодировками хуже некуда. Обмен информации с виндусёвыми системами через usb-брелки/диски не работает. И можете 100 раз объяснять теткам в бугалтерии, что на самом деле нужно называть файлы английскими именами! В свете descktop 4 эту проблему нужно решать. Хотя бы прибить гвоздями. Или написать морду для правки полиси hal'а. Хм... Мой(и не только мой) мазохизм принес свои плоды - при работе в utf-8 особого дискомфорта, спустя 1.5 года, уже никто не испытывает... Любители более других, не мейнстрим кодировок, сами способны разобраться с настройками, а остальным давать еще одно ружье для выстрела в ногу смысла нет.IMHO. снова воспроизводится. как правильно теперь править? локаль кои8 На мантейнера, если снова воспроизводится. теперь правильно локаль UTF-8. кричать что "мине роднее koi8-r/cp1251" смысла не имеет Проголосуем за альтернативный пакет hal с альтернативным мантейнером, который слышит? Или дружно перейдём на UTF8? А при чём тут hal, если опции монтирования ему передаёт "программа-монтировщик"? pmount, gvfs, что-там-в-KDE. В hal сейчас прописаны только valid-options. в результате таки съехал на utf8. времени заняло от силы минут 5-10 (convmv прошерстил 250 гб данных в /home). вот и пал мой последний бастион 8-ми битной локали (оставалась скорее исторически). |
