Что делать с максимальной длинной пути в линуксе при копировании файлов с винды?

И действительно ли все эти 4095 символом можно использовать?

Да, можно. Только учти, что это 4095 ASCII символов. А имена файлов закодированы в UTF-8 скорее всего. А там, например, русские буквы занимают 2 байта.

А можно тогда расширить эту структуру? Или тогда нужно будет и glibc пересобрать?

Ограничение в 4095 байт вряд ли тебя как-то коснётся, так как в Windows эффективное ограничение на длину пути — 260 символов. Конечно, Windows может и больше, но очень много сторонних программ имеют ограничение именно в 260 символов.

Что тебя коснётся, так это разность между символом и байтом. В Linux большинство ФС имеют ограничение на длину имени в 255 байт, тогда как в Windows это 255 символов. Если используется многобайтная кодировка вроде UTF-8, символов в имя влезает меньше, и это как раз вызывает проблемы.

Часто можно встретить мнение, что ограничение в 255 байт зашито в VFS, но это не правда (по крайней мере, сейчас). Ограничение вшито в сами ФС. Я смотрел на эту тему код ext4 и reiserfs. В ext4 под длину выделен один байт, так что больше 255 позиций там сделать точно нельзя. В reiserfs принципиальное ограничение — размер блока минус что-то там, то есть чуть больше 4000 байт. Но и там просто константой длина ограничена 255 байтами. В FUSE ограничение — 1024 байта, поэтому можно через неё подцепить ntfs-3g и писать туда. Можно ещё сделать прокси-ФС на FUSE, отображающую длинные имена в более короткие. Я так пробовал сделать, оно даже работало, но довольно криво — не доделал.

Спасибо за столь подробый пост. Можете уточнить про вариант с FUSE? И можно ли просто с iocharset и charset/codepage примонтировать? Есть ли ФС, у которых нет таких проблем (кроме ntfs-3g)? У ядерного драйвера NTFS нет проблем?
И Вы, случаем, не в курсе, что делает опция монтирования uni_xlat?

Можете уточнить про вариант с FUSE?

Так как в случае с FUSE можно писать свою ФС, ограничения в 255 байт делать никто не заставляет. Я делал вот так: https://github.com/i-rinat/insecure, оно хранит имена в SQLite. Но предупреждаю, этот код реально кривой.

Ответ на каждый из остальных вопросов: «не знаю».

Можно ли её расширить ?

Вот тут написано кое-что: http://wiki.etersoft.ru/Linux/VLFN

Спасибо. Звездец какой-то: на дворе 2015 год, а нас до сих пор проблемы с переносом файлов из одной системы на другую.

на дворе 2015 год, а нас до сих пор проблемы с переносом
файлов из одной системы на другую.

Как-то, пару лет назад, гуглежом по «utf8 ограничение linux», или что-то в этом роде, наткнулся на обсуждение в lkml, где бездействие аргументировалось тем, что в европейских языках более 2 байт имеют единицы символов, а там, где иероглифы, одного-двух иероглифов на всю фразу хватает, и что там и 6 байт бывает, роли не играет. В общем, проблемы только с кирилицей, арабским и прочими аналогичными. Где и не латиница однобайтовая, и не слово целиком в символе.

Вот повторно найти никак не могу ту ветку, года полтора ищу уже, время от времени.

Надо кому-нибудь протолкнуть бОльшую длину имени файла в ext5.

гуглежом по «utf8 ограничение linux»,

Ой. Конечно же, не по-русски. :-)

Не надо копировать напрямую из винды в линукс — это две абсолютно разные системы.

Так же можете повозмущаться, что винда не позволяет в именах файлов все символы доступные в линуксе, а ведь блджад, 2015 год на дворе, а винда все еще ущербная, нельзя копировать напрямую из линукса в нее убогую

Не надо копировать напрямую из винды в линукс — это две абсолютно разные системы.

Надо. Обратно - не надо. :-)

Вот повторно найти никак не могу ту ветку, года полтора ищу уже, время от времени.

Нашёл !! Не lkml, а linux-ext4:
http://www.spinics.net/lists/linux-ext4/msg10187.html

Sure, but 85 characters is a lot, given that each character might be
the equivalent of multiple letters. For example the English word
«country», which takes six characters, or 6 bytes in UTF-8, can be
encoded as a single Chinese ideograph, which can be encoded in 3 bytes
in UTF-8. Something like «United States of America», is encoded in 24
bytes in English, and 6 bytes (two ideographs) in Chinese in UTF-8.
My name, «Theodore Yue Tak Ts'o», takes 21 bytes in English and UTF-8.
In Chinese, it's 3 ideographs, or 9 bytes in UTF-8. I'm choosing
fairly basied examples here, of course, but I think it's in general
true.

As a final example consider, «The Tao which can be described is not
the true Tao». This can be expressed *much* more succiently in
Chinese. :-)

Надо кому-нибудь протолкнуть бОльшую длину имени файла в ext5.

Большая длина имени не нужна, нужно всего лишь хранение имени в UTF-16 как это сделано в NTFS.

Напиши Линусу, чтобы показал фак разрапботчикам glibc или что там мешается.

МОИДОК~1

ТвоиДоктора?

нужно всего лишь хранение имени в UTF-16 как это сделано в NTFS.

Думаю, это сложнее сделать. Собственно, чтение земетки от Etersoft показывает достаточную простоту решения с обычным увеличением значения переменной (для btrfs, по крайней мере). А в случае подразумевания, что это не байт, а символ, надо будет уже код лопатить.

Большая длина имени не нужна, нужно всего лишь хранение имени в UTF-16 как это сделано в NTFS.

А в чём профит-то перед утф-8? Длина сивола всё равно переменная.

Очевидно, нужно свериться с таблицей и выбрать ФС с более мягкими ограничениями на длину имени файла. Применительно к онтопику сходу можно предложить складывать на hfsplus. Ещё про запас есть vfat (правда с известным ограничением на максимальный размер файла) и ntfs (-3g через FUSE, который уже писали). А так во всех трёх работает 255 символов UCS.