Как увеличить лимит 255 символов на имя файла

А программы такой финт ушами нормально переварят?

Ну, если каждая программа ещё и длину имент файла проверять будет...

Ну, если каждая программа ещё и длину имент файла проверять будет...

А в программе подобного лимита быть не может, что она такие файлы просто-напросто не сможет прочитать?

Вангую что ограничение в 255 не только и даже не столько в ядре как скорее всего в системных библиотеках.

длина в Linux все-равно не более 255 символов

Ибо нефиг. А тебе зачем, торенты качаешь?

На macOS

Есть ли смысл патчить ядро и что именно там надо патчить

Вот тут кое-какую работу провели: http://wiki.etersoft.ru/Linux/VLFN

Что сделал несколько лет назад на своём ноуте:

1. Увеличил в ядре (include/uapi/linux/limits.h) NAME_MAX и XATTR_NAME_MAX до 1023.

2. Для ReiserFS увеличил REISERFS_MAX_NAME(block_size) до 1023. (Пользуюсь постоянно, с проблемами не сталкивался.)

3. Для Btrfs увеличил BTRFS_NAME_LEN до 1023 (в ядре) и в btrfs-progs. (Опыта с этой ФС имею мало, но вроде всё нормально.)

4. Reiser4 работает как надо в этой части без необходимости подкручивания чего-либо. (Жаль, что не в ядре. Но опыта тоже немного.)

5. Это всё, что можно относительно просто сделать - остальные ФС (включая XFS и F2FS), насколько могу судить по своим неудачным потыткам и беглому просмотру их кода, просто так не изменить. Особенно удивили NILFS и F2FS, запиливаемые азиатами, странно, что их эта проблема не интересует.

6. Ну и напоследок увеличил в CUPS значение IPP_MAX_NAME до 1024.

PS. Было бы крайне интересно получить опровержение по п.5. Кстати, мои попытки по ним совсем свежие.

Спасибо за инфу тебе и анонимусу ниже

Ибо нефиг.

Отнюдь нет.

А тебе зачем, торенты качаешь?

Научные публикации храню. Много. Не переименовывать же их.

Не переименовывать же их.

Почему бы и нет - используй хэш вместо имени и каталог названий. Можно тупо файлик хэш -> название, можно БД замутить.

странно, что их эта проблема не интересует

Дык у них символы хоть и длинные, зато слова короткие. Даже если использовать слоговое письмо, а не иероглифы, выйдет наверное короче чем русский текст. Не говоря уже про всякие ромадзи, или пиньинь.

Есть ли смысл патчить ядро

В дефолтном ядре для FUSE ограничение стоит не 255, а 1024 (или 1023?) байта. Поэтому, например, для ntfs-3g, имена могут быть длиннее.

запиливаемые азиатами, странно, что их эта проблема не интересует.

Как раз нет: один иероглиф занимает много байт, но и сам значит сильно много.

у них символы хоть и длинные, зато слова короткие.

Точно. Значит можно и не надеяться, что в этих ФС появится поддержка очень длинных имён...

Беглый взгляд показал, что таки да, он может выползти немало откуда.

Спасибо, интересно, что первая ссылка там как раз на ЛОР =)) Но это для своего дистра надо вручную патчить ядро, glibc и btrfs, но тем не менее... Проблема серьезнее чем думал, хотя и есть варианты решения.

Тоже любопытно.

Народ, ну и пропихните это всё в соответствующие проекты, у кого что получилось, а мы поддержим это всё поддакиванием в списках рассылки соотв. проектов. Только ссылки сюда скиньте, чтобы знать куда ходить.

Подписываюсь на тему. Не знаю зачем мне оно надо, но оно надо!

Народ, ну и пропихните это всё в соответствующие проекты

У Линуса ЧСВ непропихивальное теперь, трудно будет. Да что там мы - Ханс не смог.

Так уже пытались? ну поросёнок.

ну и пропихните это всё в соответствующие проекты

А что пропихивать то?

ReiserFS, Reiser4 и Btrfs вполне себе работают (требуют только изменения константы, а в случае Reiser4 не надо и этого делать). Спасибо за это Гансу (Мейсон ведь тоже у него работал, так что очень условно можно сказать, что корни одни). Отдельное спасибо тем, кто поддерживает Reiser* в актуальном состоянии и даже развивает.

Изменить константу, наложить патчи и пересобрать - это всё относительно просто.

А вот со всеми остальными линуксовыми файлухами всё намного сложнее - надо менять структуры хранения данных (мне бы очень хотелось ошибаться в этом). В условиях, когда это не надо их авторам, да и большенству наших это не очень актуально, затея представляется утопичной из-за сложности и отсутствия ну очень заинтересованных в этом лиц.

Значит проще одной ногой колесо крутить, другой пружину прижимать, а руками рулить и бибикать? И так каждому кто заинтересован? Да, оно не так чтобы совсем горит, но если это запилить в мэйнстриме, то всем остальным останется только следовать стандартам. А лишняя длина имени карман не тянет.

У Линуса ЧСВ непропихивальное теперь, трудно будет

Дык, надо через Леннарта заходить. Чо как не русские-то.

Дык, надо через Леннарта заходить. Чо как не русские-то.

В смысле работать на красную шляпу?

В смысле работать на красную шляпу?

Просто подкинуть ему идею про vfsd.

Значит проще одной ногой колесо крутить, другой пружину прижимать, а руками рулить и бибикать? И так каждому кто заинтересован?

Маргиналам не привыкать.

Задачу максимум (увеличение длины имени файла в самом ядре и включённых в него ФС) просто так не решить, это идеологический вопрос, который уже неоднократно поднимался, без результата. (Что-то не слышно при этом про большую активность разработчиков отечественных дистрибутивов, а уж они то должны быть заинтересованы.)

Задача минимум (дать пользователю возможность задать константу в произвольной ФС) требует написания кода. Зачем это делать, если можно просто взять Reiser4|Btrfs|ReiserFS? То есть задача усложняется, т.к. необходимы условия VLFN + невозможность использования Reiser*|Btrfs + способность писать код для ФС. Ну и где в живой природе это можно встретить? Так что патчей нет и продвигать в этом плане нечего...

vfsd

что есть vfsd?

надо через Леннарта заходить

Но это ведь будет Linux-specific решение?

А вот POSIX спасёт всех поголовно.

Интересное мнение из сообщения 2008 года:

It's very difficult to solve all these problems in the kernel, libc,userspace, I know, but I think we should keep the option to fix themin the future. Maybe in the next POSIX standard, we should changeNAME_MAX to [255 * max_bytes_per_character] ?

Так что желающие могут попытаться зайти через Российскую секцию IEEE.

PS. Если кто может, исправьте link выше. Это ссылка на сообщение содержащее цитату.

А не проще начать хранить содержимое файлов ВНУТРИ файлов?

А не проще начать хранить содержимое файлов ВНУТРИ файлов?

Вот представь себе: приносят тебе уже ГОТОВЫЕ файлы с длиннющими именами в кириллице.

Ты реально будешь в такой ситуации переименовывать эти файлы?

А если ты эти файлы должен будешь отдать дальше по workflow?

Мне БД вполне заменяет при этом нормальная ФС + Emacs с Helm. Зачем огород городить?

Если проблема с русскими названиями, то можешь попробовать:
https://yadi.sk/d/hoDr_XYa3Gfps8
Зачмодить +х и использовать так: ./fuse_handle_long_names ~/Downloads/ ~/MYFS
Потом качать торренты в ~/MYFS
(русские длинные файлы будут транслитерированы, (а английские вроде должны обрезаться))

Правда, возможны баги:
https://sourceforge.net/p/fuse/mailman/message/35559666/
Если кто вкурсе что это и почему — поясните

255 * max_bytes_per_character

2017

Ещё и делать не константную константу, фу.

Ещё и делать не константную константу, фу.

Это детали. Главное, тот чел указал направление - через изменение стандарта POSIX.

Вот представь себе: приносят тебе уже ГОТОВЫЕ файлы с длиннющими именами в кириллице

Мне проще представить сову с письмом из Хогвардса. Тем более, что это намного реалистичнее.

Мне проще представить сову с письмом из Хогвардса. Тем более, что это намного реалистичнее.

Видимо, Linus и большинство разработчиков ФС тоже так рассуждают(((

А пока имеем:

Etersoft bug 9266

Status: DEFERRED

Importance: P4 minor

А мне нет, потому что тему я и завел из-за того, что слишком длинные кириллические имена файлов не копируются под линуксом.

Да все уже поняли, что современная тенденция: прототипы, работающие в тепличных условиях, без тестирования и релизов. Явно быстрее сова прилетит, чем сделают надежный софт.

Да здесь подобные темы уже неоднократно возникали. Вот, и месяца не прошло.

И как всегда находятся сторонники решения проблемы путём переименовывания файлов... Забавное возражение встретилось где-то типа StackOveflow, дескать зачем вам увеличение длины имён файлов, ведь их будет трудно читать)))

Надо делать какой-нибудь костыль, поверх всего, что бы ничего не сломать.

На основе fuse и парсинга файловой структуры. Давать vfs служебные короткие имена для этих файлов, а где-то отдельно иметь доступ к полным.

Надо Линусу пропихнуть важный для него файл, в не ascii-кодировке имени, который он не сможет даже загрузить на свой Linux. Тогда мигом что-то изменится, а так проблемы они там не хотят видеть.

Кстати, он шведский/финский еще не забыл? На этих языках что-то такое можно сварганить?

Или через детей: помнится, он на сусю наехал, что его домашние не смогли к вайфаю подключиться, потому что рута требовало. Надо втереться в доверие в школе/колледже к его детям и повлиять. Или к жене :)

«Дорогой, мне тут знакомый дал доступ на cifs шару, с новыми лекалами для шитья и хендбуком о венгерской вышивке, но я не могу их просмотреть. Давай, пиши в мейлист мальчикам Тео и Жоре, пусть разбираются. Никаких чпок-чпок, пока не починишь!»

А можно просто дать ссылку на этот пост :)

Забавное возражение встретилось где-то типа StackOveflow, дескать зачем вам увеличение длины имён файлов, ведь их будет трудно читать)))

И btw логика в этом есть. [стеб] Давайте тогда уж вернемся к старым временам когда директорий не было, не а че, будем все называть длинными именами... типа home-users-1-2-3-4-5-6-7-..-N.avi[/стеб]
Если серьезно, то конечно проблема есть, раз столько тем возникает. Да и мне приходилось сталкиваться с подобной проблемой «переноса» «длинных имен».

Понятно, что стёб, но мне вот уже всё равно - хотят юзеры прислать «Войну и мир» в виде названия файла, да ради бога. Удобно им значит так. Терпимее надо быть к таким.

Из двух зол, «вот уроды, прислали мне файл с длинным именем» и «вот уроды, они не дают мне возможность создать файл с длинным именем» решительно выбираю первый вариант.

Научные публикации храню. Много. Не переименовывать же их.

Эх, приснопамятный проф. Луговской бы сейчас объяснил, что такие вещи надо хранить в БД, а такие смешные системные сущности как файлы, обычному пользователю не нужны совсем...

Если серьёзно - ну что, ты полное название публикации именем файла делаешь? Это не очень практично. Там ведь и спецсимволы могут попасться. Группируй их для ориентировки в подкаталоги - по авторам, по тематике - а для поиска надо другие средства задействовать.

Зачем?