Что делать с максимальной длинной пути в линуксе при копировании файлов с винды?
При копировании файлов с винды не редко сталкивался сталкивался с ошибками о максимальной длине пути.
Длина имени файла = 255 байт?
Согласно этому треду максимальная длина пути Length of pathname is 4095 chars. (limit of kernel) . Можно ли её расширить? И действительно ли все эти 4095 символом можно использовать?
Причём сталкивался с этим не только при копировании файлов с виндовых компов по сети (особенно часто url-файлы имеют очень длинный путь), но и при загрузке торрентов. Предвкушаю проблемы с переносом профилей или файловых помоек винды на самбу, а также проблемы с rsync и бекапами.
И действительно ли все эти 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. Но предупреждаю, этот код реально кривой.
Ответ на каждый из остальных вопросов: «не знаю».
Источник
Максимальная длина имени файла
Как на линуксе делают nas для виндоус клиентов если с utf8 длинна русского имени файла не может быть больше 130 символов а японского 80. Может лайфхак какой есть для обхода ограничений?
Если кодировка в системе русская однобайтная то можно делать русские имена 255 символов длиной но при этом все символы которых нет в этой кодировке вызывают ошибку слишком длинное имя.
Может есть такая utf кодировка в которой русские буквы 1 байт занимают
Я не в курсе технических ограничений samba, но из твоего текста я так понимаю там есть какое-то ограничение в 256 байт на имя файла.
В utf8 символы могут занимать от 1 до 4 байт. А в utf16 всегда 2 байта. Я бы использовал utf16 и получил константные 128 символов на имя для любых языков.
Может лайфхак какой есть для обхода ограничений?
Нет. /thread (потому что других вопросов я не увидел, а на этот ответ однозначный).
Всегда два байта в UCS-2. В UTF-16 может быть два или четыре байта на символ (а может уже и больше, тут не уверен).
Я бы использовал utf16 и получил константные 128 символов на имя для любых языков.
В линуксе имя файла может содержать любые байты, кроме ‘/’ и ‘\0’ . Так что работать твоё предложение совершенно точно не будет. Пример:
Источник
Ограничения длины имени файла в linux?
Существуют ли какие-либо ограничения на длину файла или длину пути для Linux?
8 ответов
См. страницу Википедии об сравнении файловых систем , особенно в столбце Максимальная длина имени файла .
Вот несколько ограничений длины имени файла в популярных файловых системах:
Я прочитал здесь , что ограничение длины пути в заголовках системы. Ограничение длины имени файла также существует. В моей системе это файл:
и C-lang определяет:
и еще несколько.
Я ссылаюсь на другие ответы, пожалуйста, повысьте их.
Существуют ли какие-либо ограничения на длину файла или длину пути для Linux?
Да, имя файла и длина пути ограничены:
Чтобы динамически получить эти свойства:
- Использовать функции pathconf и fpathconf , предложенный Майкл Аарон Сафьян
- Создайте имя файла (или путь) дольше и дольше, как описано dogbane .
Используйте команду getconf , предложенную tim , которая также доступна в Linux:
И ради экономии времени (и привязки к памяти):
ext2, ext3, ext4, zfs: нет ограничений пути; Ограничение имени файла 255 байтов.
Это длина имен файловой системы. У самого «linux» тоже есть. Например, из бит /stdio_lim.h:
Существует no way , чтобы определить максимальную длину путей в Linux портативным способом. В моей системе:
Но я могу легко создавать дорожки длиной более 4096 символов. Вместо этого посмотрите PATH_MAX как нижнюю границу. Вы гарантированно сможете создавать пути так долго, но вы также можете создавать гораздо более длинные.
Вы всегда должны использовать pathconf или некоторые функции, подобные этому, чтобы получить значение времени выполнения для указанных элементов, так как это страница говорит, что:
Следует отметить, однако, что многие из перечисленных ограничений не являются инвариантными, а во время выполнения значение предела может отличаться от значений, указанных в этом заголовке, по следующим причинам:
Предел зависит от пути.
Предел отличается между машинами компиляции и времени выполнения.
По этим причинам приложение может использовать функции fpathconf (), pathconf () и sysconf () для определения фактического значения предела во время выполнения.
Он указан в системном файле limits.h .
Вот один из этих файлов:
Здесь находятся копии этого файла и значения, которые они определяют:
Источник
Длинные имена файлов
Всем привет переношу файлопомойку с винды на линукс. Столкнулся с проблемой «очень длинных имён файлов». Похоже, счёт идет не на символы, а на байты (гугление это подтверждает). Внимание, вопрос: мне таки придётся использовать винду или есть какое-то решение этой проблемы? (усекновение имени — не решение в данной ситуации)
ext2/3/4,reiser,xfs,jfs — все поддерживают 255 символов в имени файла (или 127 в UTF8) — куда вам больше??
Поправочка: 127 русских букв, закодированных в UTF8.
UTF8 — однобайтовая кодировка, так что ASCII в UTF8 = ASCII 🙂
ФС те, которые поддерживаются CentOS 5.4 — то есть ext2/3, ext4 без mkfs.ext4, xfs на положении ext4.
127 букв — внезапно оказалось мало. Есть у пользователей такие имена файлов:
«Котов АН Моделирование дорожного движения на многополосной магистрали при помощи двумерного вероятностного клеточного автомата с тремя состояниями, 2008 (диссертация)»
Усекновение — не вариант. На винде такое имя файла обрабатвается корректно
$ echo «Котов АН Моделирование дорожного движения на многополосной магистрали при помощи двумерного вероятностного клеточного автомата с тремя состояниями, 2008 (диссертация)» | wc -c
$ touch «Котов АН Моделирование дорожного движения на многополосной магистрали при помощи двумерного вероятностного клеточного автомата с тремя состояниями, 2008 (диссертация)»
$ ls Котов*
Котов АН Моделирование дорожного движения на многополосной магистрали при помощи двумерного вероятностного клеточного автомата с тремя состояниями, 2008 (диссертация)
Вроде создался файл. ext3.
Если очень нужно, то можно поставить однобайтную локаль. Хотя да, не решение.
Источник
Ограничение на название файла
При переносе файла с windows в linux столкнулся с проблемой при копировании, слишком длинное имя файла (файловая система ext4), можно каким либо образом обойти данное ограничение? При том если бы данный файл был один можно было бы переименовать, но таких файлов больше 500, и как бы не вариант.
Это одна из наболевших проблем.
VFS уже поддерживает более длинные имена, но во многих ФС всё ещё однобайтная длинна. Если надо имена и не использовать виндовые ФС, то можно попробовать другие FUSE ФС, или «починить» ReiserFS в ядре.
Можно переименовать все файлы однострочным скриптом.
а) вместо ext4 используй reiserfs, б) вместо хрюникода поставь однобайтную локаль.
Ну, а можно на лету переименовать в транслит:
А вообще, лучше никогда не использовать в именах файлов запрещенные символы (спецсимволы и символы вне таблицы ASCII).
Если это плановый переезд, список файлов «в зубы» юзверам и нехай переименовывают. Но обязательно со сроком, типа «кто не спрятался я не виноват».
Вендузятники должны стадать.
Имена файлов, очевидно, в кириллице. В таком случае однобайтная локаль, например KOI8-R, позволяет увеличить лимит на количество символов в именах файлов, поскольку лимит на имена файлов именно в байтах, а не в символах.
А в венде когда длинные пути сделают? Или это надо включит совместимость нтфс (это там где имена пара символов капсом с тильдой) чтобы оно нормально воспринимало? МС рекомендует не включать из-за проблем с производительностью.
Про тильду не знаю, но у меня так и не получилось снять ограничение в 260 символов по их статье в KB. Проводник и многие другие программы так и переставали работать с объектами за 260. А если для каких-то программ ограничение и снялось.. Поэтому файлы массово я всегда двигаю через 7-zip, чтобы неожиданно ошибка не вылезла.
Только страдать в данном случае приходится линуксоидам 🙂
Но страдают тут Linux’оиды со своим обрезанным короткопутём в 4К байт.
Можно подумать, у вантузятников путь не 4кБ ограничен.
А уж про максимальную длину имени файла вообще не надо байки рассказывать: она у всех равна 255 символам. Но любители хрюникода должны страдать, поэтому у них длина имени в самых печальных случаях составляет всего-то 63 символа!
Одной ФС тут не обойдёшься.
можно каким либо образом обойти данное ограничение?
Но страдают тут Linux’оиды со своим обрезанным короткопутём в 4К байт.
На самом деле не страдают — нет привычки «Войну и мир» умещать в имя файла. 🙂
в исходниках linux есть limits.h, где есть такие строки
Незнаю что получится из смены локали, тут ведь все завязано на 1с с postgresql — а там utf8, или одно с другим не зависят, но не уверен. Да и если менять тип файловой системы все отформатируется — эх а всплыло это все, когда уже все настроено и из-за такого все.
Бить по рукам юзверей, а для копирования файлов завести скрипт, который будет на лету заменять запрещенные символы, преобразовывать имя в транслит и обрезать его по первым 40 символам (чтобы имя хотя бы в две колонки в монитор влезало).
Лучше просто их бить )))
Функция rmspaces заменяет все пробелы на символы подчеркивания.
Мдэ. Делов то поменяйть s/?/_/g на s/[[:space:]?]/_/g
Умничка. Осталось поменять для каждой из фс в ядре и для всех утилит каждой из фс в юзеоспейсе. И не надо забывать про кучу малу gvfs, udisk и прочих прочих прочих.
Только страдать в данном случае приходится линуксоидам 🙂
Лал а ничего что мне с reiser4 норм а вендузятнечки с чего то посасывают.
Для этого нужно скрипт написать, т.к. просто ‘*’ не взлетит!
вендузятнечки с чего то посасывают.
Ты так гворишь, как будто они это делают не в своё удовольствие. Они ж все специалисты по оральной гигиене.
Ты их с гейосниками не путай. Вантузятники просто дерьмо жрут и причмокивают.
Почитай сверху ссылку. И ещё Как увеличить лимит 255 символов на имя файла. Это не влияет на ядро, а на некоторые программы. В ядре давно этого ограничения нет, но во многих ФС там константа в байт. Точнее, для первых extfs, вроде, поле хоть и было однобайтное, дальше были неиспользуемые байты. Хотя можно было расширить поле, решили задействовать «лишние» байты под новые поля. reiserfs и raiser4 изначально имеют большие поля, но reisers, через некоторое время после принятия в ядро, пропатчили установив ограничение.
Источник
