Как узнать кодировку, в которой смонтирована fs?

в юзерспейсе:

посмотреть опции монтпирования файловой системы в файле /proc/mounts и выводе команды mounts

PS: не все ФС имеют такую опцию:
    Например для ext2/3, reiserfs3/4, xfs, jfs, nfs такой опции не существует ибо безсмысленны. 
    Существуют для vfat, iso9669, smbfs как виндузные атавизмы

>такой опции не существует ибо безсмысленны.

кто тебе это сказал? попробуй примонтировать ext3 используемый например на компе с koi8-r на комп c utf-8, отнюдь не бесмысленны,
просто никто не сделал.

>попробуй примонтировать ext3 используемый например на компе с koi8-r на комп c utf-8,

пробовал

>отнюдь не бесмысленны,

в противном случае их бы не привязывали к конкретной FS а сделали общими на все фс

>в противном случае их бы не привязывали к конкретной FS а сделали общими на все фс

поясни IMHO ananymous в данном случае прав.

анонимус прав в том случае когда он один сидит за компом под рутом и без никаких юзеров в системе.

а если в системе тысяча пользователей, у каждого своё окружение($LANG и иже с ним), то скажите мне в какой кодировке монтировать корневую фс?

> а если в системе тысяча пользователей, у каждого своё окружение($LANG и иже с ним), то скажите мне в какой кодировке монтировать корневую фс?

для этого fs должна быть [в идеале] в unicode и осуществляться трансляция имен на уровне окружения пользователя. например, в libc. если так хочется.

// wbr

теоретически - да

но записать имя файла в ucs32 на posix-compatible в ближайшем будущем не удастся а utf на уровне ядра даст повод всем подряд кричать что линукс-тормоз.

а вообще кому не нравится пользуются plan9. там таких проблем не существует

> но записать имя файла в ucs32 на posix-compatible в ближайшем будущем не удастся

именно UCS32 - да, потому что есть только UCS-2 и UCS-4. слава богу, до UCS-32 еще весьма далеко..

а для UCS-2 [16ти битные символы] - какие собственно препятствия?

> а utf на уровне ядра даст повод всем подряд кричать что линукс-тормоз.

почему? аргументы?

// wbr

>>но записать имя файла в ucs32 на posix-compatible в ближайшем будущем не удастся

>именно UCS32 - да, потому что есть только UCS-2 и UCS-4. слава богу, до UCS-32 еще весьма далеко..

извиняюсь имел ввиду ucs-4, тем не менее последний периодически обзывают ucs32, возможно по безграмотности или путают с utf-32

>а для UCS-2 [16ти битные символы] - какие собственно препятствия?

а оттудова что posix предполагает ноль-терминированные имена файлов а набор символов ascii содержит нулевой байт в каждом символе.

> извиняюсь имел ввиду ucs-4, тем не менее последний периодически обзывают ucs32, возможно по безграмотности или путают с utf-32

AFAIU путают по разрядности символа в битах. но называется это в том-же UNICODE 3.0 все-таки UCS-2 и UCS-4 (соотв. 2 и 4 байта на символ, 16 и 32 бит).

> а оттудова что posix предполагает ноль-терминированные имена файлов а набор символов ascii содержит нулевой байт в каждом символе.

UTF-8? как это и хранится собственно на моей fs.

ps: с точки зрения ядра OS совершенно по барабану, в какой кодировке/формате хранятся имена файлов. вся обработка идет на уровне приложения пользователя и перекодировка UTF-8 <-> UCS-2 - это далеко не самая дорогая операция при обработке. например, сортировка может быть значительно дороже.

// wbr

>с точки зрения ядра OS совершенно по барабану, в какой кодировке/формате хранятся имена файлов.

ну насколько я знаю sys_щзут всётаки по \0 ищет конец имени файла так что utf16 ucs2 ucs4 в текущее линуксовое ядро не запихнёш никаким боком. а вот в plan9 ядро насквозь ucs4. как они этот трабл решили я незнаю но нулевые байты в имени фала точно разрешены

>sys_щзут

извиняюсь

sys_open