LINUX.ORG.RU
ФорумAdmin

Длинные имена... как хранить?

 , , long filenames,


0

5

Собственно суть в subj.
Не редкость в торрентах и/или рабочих корпоративных системах хранятся файлы с длинными именами на русском языке. Для себя переименовать обычно не проблема, исключая торренты(вроде и там можно переименовать, но не все клиенты поддерживают это).
Из файловых систем поддерживающие длинные имена (Linux) был reiserfs - которого ныне удалили из ядра.
Из оставшихся - по сути только ZFS наверное.. Да ещё привлекательно выглядит HAMMER под DragonFly BSD.
Для ext4 готовят установку кодировки, но ещё не доделана, поэтому только UTF8, соответственно длинна режется вдвое.

Сижу перед выбором...

Кто как решает проблемы(кроме административных способов)?
Оптимально также сообщить - для дома или для конторы.

★★★★★

https://github.com/openzfs/zfs/issues/13043

где там написано, что она поддерживает длинные имена?

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

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

Под длинными именами я понимаю хотябы 256 символов, а не байт как у большинство систем.
для ZFS указано 1023 bytes https://en.wikipedia.org/wiki/Comparison_of_file_systems

Atlant ★★★★★
() автор топика
Последнее исправление: Atlant (всего исправлений: 1)

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

$ & {                          
      $s = $('a' * 256)
      $ss = $s -split '(?<=.)(?=(?:.{64})+$)'
      $dir = $ss[0..($ss.Count - 2)] -join "/"
      mkdir "Desktop/$dir" -p
      $null > "Desktop/$dir/$($ss[-1])"
      tree ./Desktop                 
    }
./Desktop
└── aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    └── aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
        └── aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
            └── aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

4 directories, 1 file

4096 в распоряжении

dmitry237 ★★★★★
()
Ответ на: комментарий от dmitry237

А как обратную операцию производить, понять что некоторые директории это часть имени файла?
А потребуется путь к файлу

└── aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    └── aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
        └── aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
            └── aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
?

superuser ★★★★☆
()
Последнее исправление: superuser (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

где там написано, что она поддерживает длинные имена?

В обсуждении там ссылка на принятый PR, 1023 байта. Там же ссылка на код Btrfs, где устанавливается лимит 255 байтов просто потому что так везде в Linux (https://github.com/torvalds/linux/blob/0c7030038e6106711c5d0b237c980905dd3244ec/include/uapi/linux/btrfs_tree.h#L22). Я думал, это намертво ограничено в VFS, а оказывается, что нет, в Btrfs технически не проблема иметь длинные имена.

anonymous
()
Ответ на: комментарий от superuser

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

$ (dir ./Desktop/a* -s | ? { $_ -is [io.fileinfo] }).FullName -replace '.+Desktop|/'

# "a" * 256
dmitry237 ★★★★★
()
Ответ на: комментарий от dmitry237

Слишком сложно. Если имя файла слишком длинное, то оно всё равно не несёт никакого смысла, кроме чтений сочинений, которые способны изменить взгляды на жизнь и вдохнуть новую жизнь в тёмные уголки сердца. Я бы просто отрезал первые 80 символов.txt

Edit: Слишком сложно. Если имя файла слишком длинное, то оно всё равно не несёт никакого смысла, кроме чтений сочинений, которые способны изменить взгляды на жизнь и вдохнуть новую жизнь в тёмные уголки сердца. Я бы просто отрезал первые 80 символов и ещё добавлял рандомное число, потому что часто бывает, что длинное название повторяется.txt

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 1)
Ответ на: комментарий от superuser

использовать выбранный символ как аналог эскейп символа

например #

если имя завершается на # это каталог сурогатный

для имён где искодно есть # заменить на ##

по классике ж

qulinxao3 ★☆
()

свой драйвер имён :(

т.е делаешь «хранилище»

для помещаемых обьетов с крвивыми именами выдаёшь возрастающие натуральные/из_какого_лексикографического_поддерева_с «заведомо невозможным у остальных „„uid““ » из незанятых для просто_имён оставляешь как есть

т.е при извлечение/чтении из «хранилища» возвращаешь имена если они в таблице есть :)

qulinxao3 ★☆
()
Ответ на: комментарий от superuser

тут «все» фонаты си

у си есть \ <- эскейп последовательности из ещё более архея

в чём трудность выделить символ из разрешённого набора и заюзать как свой аналог ?

qulinxao3 ★☆
()
Ответ на: комментарий от superuser

дык фс и есть иерархическая|«сетевая» БД до кодда при «кодасил» Бахмана - навигаторы программисы http://rkka21.ru/docs/turing-award/cb1973r.pdf http://rkka21.ru/docs/turing-award/cb1973e.pdf

The Programmer as Navigator by Charles W. Bachman

[1] https://dl.acm.org/doi/pdf/10.1145/355611.362534 https://dl.acm.org/doi/10.1145/355611.362534

чисто сравни с «привычными БД» http://rkka21.ru/docs/turing-award/ec1981r.pdf

qulinxao3 ★☆
()
Последнее исправление: qulinxao3 (всего исправлений: 1)
Ответ на: комментарий от qulinxao3

Ну если так, то какую-то фиговую БД сделали (обосрались), если больше 256 символов не поддерживает
Ps: Мне конечно пока и 256 хватает

superuser ★★★★☆
()
Последнее исправление: superuser (всего исправлений: 4)
Ответ на: комментарий от superuser

дык fat-12 от бойсика просто односвязные списки и это прорыв вместо прямого блочного именования как в форте и тех современиках

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

qulinxao3 ★☆
()
Ответ на: комментарий от superuser

А что мешает файлы вместе с именами хранить в БД? Другой вариант, как выше – файл с сопоставлениями имëн, а сами файлы переименовать хэшами от имени. Можно сами файлы и в tar-архиве хранить.

yars068 ★★★★★
()
Последнее исправление: yars068 (всего исправлений: 1)
Ответ на: комментарий от superuser

https://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf /The PDP-7 Unix file system/

640к хваит всех

дык и односвязные было оверкил

как и 8 байт на всё почти в два раза больше 5

расширения в CP/M ( ака контроля программа/микрухи ) ваще еnum а не аж 3 байта

qulinxao3 ★☆
()
Ответ на: комментарий от superuser

Это исторически сложилось, и да, оно устарело. Потому что 255 символов в многобайтных кодировках, в итоге максимальная длина имени будет уже меньше 255 символов.

yars068 ★★★★★
()

cм duckdb

в части структур хранения данных всяких паркет эрроу

ибо ща память настолько разнообразна (регистры кэш озу(всякая) ссд нжмд сеть облачно) с настолько разными латенсями что структуры хитроданных актуальны

qulinxao3 ★☆
()

Кто-то на форуме находил или писал fuse систему с поддержкой длинных имен именно под торренты, типа качаешь туда переименовываешь и убираешь на ext4 раздел. Поищи в этом направлении.

Kolins ★★★★★
()

Проблема с длинными именами в Linux решена ZFS. Работает отлично. Больше не требуется ничего патчить. Если ZFS поддерживается вашим дистрибутивом, то всё просто.

anonymous
()
Ответ на: комментарий от CrX

Предположу, что имя файла формируется по особым правилам. Например, Автор: Заглавие.pdf. И в случае Л.Н. Толстой: Война и Мир это работает весьма не плохо. А вот если у нас коллектив авторов в пятнадцать человек и статья «Введение в проблематику того, сего и этого с учётом разных факторов в свете новых открытий в областях геометрии, географии, геодезии и геологии», тут файловой системе может и поплохеть.

ugoday ★★★★★
()
Ответ на: комментарий от yars068

это крайне редко встречается

Потому что Господь милостив!

никто особо и не чешется.

Но Дьявол хитёр и в этом нашем айти лучше лишний раз не чесаться.

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

ugoday ★★★★★
()

Из файловых систем поддерживающие длинные имена (Linux) был reiserfs - которого ныне удалили из ядра.

Там тоже ограничение в 255 байт. Теоретически Reiserfs могла поддерживать имена до примерно 4 килобайт, но по факту там был установлен лимит в 255 байт.

Ограничение в 1024 байт доступно файловым системам, работающим через FUSE.

i-rinat ★★★★★
()
Ответ на: комментарий от rtxtxtrx

файловые системы работают через vfs. это у нее ограничения в 255 символов

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

i-rinat ★★★★★
()
Ответ на: комментарий от CrX

Ни разу не сталкивался с такой проблемой в торрентах. Это что за имя должно быть, что оно в 256 байт не влазит (даже на русском), а главное зачем…

Ну я с таким столкнулся лет 5 назад, когда пытался сохранить старый бекап телефона в /home/necromant/data/windows7_backup/D/home/necromant/data/phone/SamsungGalaxy/backups/2020-07-11/, а нехороший Самсунг решил чрезвычайно интересно и витеевато называть директории у себя, которые вышли за оставшийся лимит в 100 символов.

А с торрентами сейчас засада такая, что аниме начали называть очень длинными тайтлами, сродни целой аннотации. Плюс привет от мультиязычных названий.

necromant ★★
()
Последнее исправление: necromant (всего исправлений: 1)