Состоялся релиз программы ratarmount 1.0.0, позволяющей работать с архивами в различных форматах как с обычной файловой системой. Поддерживается работа с форматами RAR и ZIP, а также архивами TAR, сжатыми при помощи bzip2, gzip, xz и zstd. Код утилиты написан на языке Python c использованием модуля fusepy и распространяется под лицензией MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62204
Хм, круто, интересно как шустро работает, а то я последнее время в качестве архивов просто стал использовать squashfs со встроенным сжатием.
Чем squashfs не устраивает?
Неудобная утилита создания образов по сравнению с tar. Приходится использовать костыль `tar | tar2sqfs`.
> Неудобная утилита создания образов по сравнению с tar. Приходится использовать
> костыль `tar | tar2sqfs`.Так alias'ом это и заколотить...
Да причём тут алиасы, набрать команду руками не проблема, факт то что это дополнительный костыль, на других хостах эта утилита может быть не доступной, а tar есть почти всегда.
> на других хостах эта утилита может быть не доступной, а tar есть почти всегда.Ну если применять эти стандарты к сабжу, так на других хостах и этого костыля точно так же быть не обязано. И профит наступает... где и в чем?
На других хостах не будет tar, xz и bzip2?
> На других хостах не будет tar, xz и bzip2?На них не будет сабжа цепляюшего их как ФС. А вот squashfs таки - зацепится обычным mount'ом, кстати. Если уж сравнивать решения 1 в 1.
А tar точно сжимает, а не просто объединяет всё в один файл, который далее и требуется сжать ?
> А tar точно сжимает, а не просто объединяет всё в один файл,
> который далее и требуется сжать ?tar - это контейнер для файлов, разработанный для архивации данных на магнитную ленту. Он сам по себе ничего не сжимает. Сжатие не сжатого тарбола производится дополнительные компрессорами, упаковщиками. По сути, опции сжатия отвечают за упаковку контейнера(тарбола), но то же самое вы можете сделать и внешним компрессором сами, результат будет абсолютно такой же. У юниксовых архивов, как правило, нет контейнеров для файлов. В отличии от виндовых, где cab, rar, zip и 7z объединяют в себе контейнер, разработанный специально для архивов, с компрессором для сжатия. Unix way за то, чтобы одна утилита делала что-то одно, но делала хорошо. tar изначально делали именно под эту философию. Они только контейнером является, а сжатие любое можно выбрать, отдельно от контейнера. Можете его сжимать, можете шифровать, можете вначале сжать, потом зашифровать. Но, каждый слой будет отдельно от остальных. А не всё вместе, как у виндовых аривов.
А я на примере tar рассказываю о недостатках unix way, рассказываю причём то же самое. Мол, смотрите, дети, что бывает при использовании этой философии за её пределами применимости.Отделили компрессор от архиватора, лишились seekability и устойчивости к повреждениям. А индекс и произвольный доступ всё равно хочется, особенно когда компрессоры вошли в обиход, а ленты ушли в прошлое, поэтому то костыли приделывали (pixz), то пытались отказаться tar (заменить на dar, но tar как фактический стандарт непоколебим).
Вернуть себе seekability в сжатом tar - значит страшно согрешить, извратить unix way полностью. Потому что приходится модифицировать один конкретный компрессор (xz), реализовывать в нём архиватор (!!), один конкретный (tar) и получать жёсткую связку из конкретного архиватора, конкретного компрессора и его нестандартной модификации с индексом (pixz). А в компрессорах-архиваторах (dar, 7z, wim) грешить не приходится и связывание оказывается даже слабее (от замены LZMA2 на BZip2 в 7z индексы не отвалятся).
В конце-концов, tar - это tape archiver. Делать что-то одно и делать хорошо - это архивировать на ленту. Случайного доступа у ленты и так нет, а сжатием она сама занимается (DLT, LTO).
* то пытались отказаться от tar
* tar - это tape archive
---
Добавлю, что других сферах lossless-сжатия разделение не прижилось (условно .wav.xz) и что архиваторы-компрессоры так же не мешают использовать внешний компрессор (отключаем сжатие и делаем .wim.zst).
> от замены LZMA2 на BZip2 в 7z индексы не отвалятсяЖаль 7z ни права доступа файлов не хранит (POSIX), ни метадату (NTFS), т.ч. tar он заменить не в состоянии (rar для ntfs вроде бы может).
Что ты там такого особенного делаешь что тебе не удобно? "mksquashfs folder folder.sqfs -comp zstd". Куда уж проще?
> Что ты там такого особенного делаешь что тебе не удобно? "mksquashfs folder
> folder.sqfs -comp zstd". Куда уж проще?Во-первых, `tar -cJvf /tmp/test.tar.xz /tmp/path/to/file1.txt` при добавлении файла в архив сохранит оригинальный путь к файлу, mksquashfs тупо бросит файл в корень.
Во-вторых, у тара привычнее работа с фильтрами по паттернам include/exclude.
С опцией "-no-strip" mksquashfs так же будет сохранять пути. Да и с фильтрами проблем не заметил: -wildcards -e -- и перечисляешь всё что хочешь исключить из архива.
Хм, интересно, в `man mksquashfs` эта опция никак не упомянута, а в `mksquashfs -help` есть, там даже обнаружилась ещё одна нужная мне опция `-one-file-system`.
И он даже может так же читать tar из stdin с опцией `-tar`, тогда и `tar2sqfs` не нужен.Я так понял это появилось где-то в версии 4.5, но manpage не обновили (косяк мейнтейнеров?).
Дурацкий вопрос.Тем что не позволяет, блин, монтировать уже существующий огромный rar–архив как файловую систему. А это питоноподелие — позволяет. И позволяет достаточно шустро с ним работать.
Почти все форматы архивов/сжатия поддерживают так называемое solid режим, в таком варианте все файлы архива "склеиваются" с друг другом и считаются одним большим блоком (или несколькими если архив по размеру большой, исходя из заданного размера блока в опциях).Так вот в таком режиме как ты не выперживайся и не кхе-кхе-кай в микрофон, а распаковать из такого архива отдельно указанный файл, без распаковки всех впереди идущих данных - нельзя. Те кто заявляют что можно, вешают вам лапшу, либо это не solid архив.
Стоит добавить что в том же rar5 режим solid позволяет сжать данные ещё лучше. Но все зависит от типа данных и количества файлов.
> Те кто заявляют что можно, вешают вам лапшу, либо это не solid архив.Ну вот да, solid RAR (а это почти все RAR на минуточку) распаковывать из середины - заманаться можно. И tar этим тоже частично страдает. Вплоть до того что там может быть "конденсированное" оглавление, а может - и по всему 100500 гиговому архиву понемногу быть раскидало. И хоть ты тресни но быстро вынуть индекс содержимого ЭТОГО - чисто технически нельзя, потому что нету там такого индекса, надо ВСЕ распаковать и отстроить из этого.
У squashfs то как раз блоки энного размера для рандомного доступа и диры с оглавлением "сконденсированы" более менее так что не надо дофига всего распаковывать чтобы только оглавление увидеть. И в итоге реально - вон то норм будет только на ZIP древнем, пожалуй.
А на огромном RAR с 100500 файлов - про нормальный перфоманс может реально только питонист вещать, видимо привыкнув к характерному перфомансу.
> Так вот в таком режиме как ты не выперживайся и не кхе-кхе-кай в микрофон, а распаковать из такого архива отдельно указанный файл, без распаковки всех впереди идущих данных - нельзя. Те кто заявляют что можно, вешают вам лапшу, либо это не solid архив.Чел, TAR.GZ - это чисто по определению solid архив. Дальше открываем страницу поекта:
Care was taken to achieve fast random access inside compressed streams for bzip2, gzip, xz, and zstd and inside TAR files by building indices containing seek points
Что конкретно тебе непонятно?
Если архив solid — это просто означает, что в нём нет индекса. Это не гарантирует отсутствия гранулярности и принципиальной невозможности извлечения произвольного файла.Да, для извлечения одного файла придётся прожевать целый архив. Если нужно извлекать разные файлы в разные моменты времени — внезапно, необязательно пережёвывать архив каждый раз. Можно при монтировании построить таблицу индексов (возможно даже со слепками состояния распаковщика для каждого файла — зависит от разновидности архива, алгоритма сжатия, настроек, ит.п.). И для этого даже не надо вываливать всё содержимое многогигабайтного архива зловонной кучей куда–нибудь в /tmp, достаточно просто циклического буфера.
И если не быть совсем тупеньким и непосредственно распаковку на питоне не реализовывать — можно даже делать это быстро. Такие–то откровения.
А что? Есть какой-то иной способ погулять по tar.gz или по tar.bz2 кроме, как сперва распаковать tar ? чудес не бывает. по крайней мере с этими архивами она будет работать очень медленно и требовать место для распаковки. и чтобы проиндексировать содержимое надо будет как минимум прогуляться по всему tar. Там нет готового списка. С остальными может и проще. Но это очередной комбайн. ПО написанное под конкретную задачу с этим справится быстрее. Что только не делают админы чтобы не учить программирование.
Мне кажется, если бы другие архиваторы научились бы хранить права на файлы и xattr файловых систем linux, то tar бы постепенно умер.В прочем, и у других архиваторов хватает своих заморочек. Вангую, разработчики слепили некую как им кажется убервафлю, которая в нужном им направлении справляется лучше чем другие приложения, но когда дойдет до широкого использования, то скорее всего не быстрее а очень даже наоборот. Плюс python со всеми его версиями и зависимости, не только лишь все справятся с установкой, так что широкого распространения не получит.
> по крайней мере с этими архивами она будет работать очень медленно и требовать место для распаковкиБудет как раз быстро. В этом кау бы и суть проекта, не? Место для распаковки не нужно - при построении индекса она происходит на лету.
> Но это очередной комбайн. ПО написанное под конкретную задачу с этим справится быстрее.
Это и есть ПО, написанное под конкретную задачу - монтирование архивов в FS - с которой оно справояется отлично.
> Вангую, разработчики слепили некую как им кажется убервафлю
А можно не ванговать, а прочесть официалтную страницу проекта. Там подробно описано, как он работает:
Care was taken to achieve fast random access inside compressed streams for bzip2, gzip, xz, and zstd and inside TAR files by building indices containing seek points.
По-моему, распаковывать архив совсем не нужно, его достаточно прочитать для составления индекса на лету, который можно сохранить в кеше на диске, а дальше уже по индексу обращаться в конкретные места архива за файлами на лету. gzip, xz и тому подобные вроде как не требуют декомпрессировать все данные, они сжимают отдельными блоками, насколько помню, поэтому имея индекс, должно быть можно обращаться почти в произвольное место архива.
А дальше тебе к примеру надо изменить файл где-то в середине архива на 20 Gb. Как это сделать? Прилепить костыль с отдельным архивом где будут храниться измененные файлы? Индекс это сам по себе костыль. Я примерно так же писал в свое время ПО для архивации почты Mdaemon, где в sqlite записывал индекс файлов в архиве, от кого/ к кому/дата/тема/"имя файла в архиве", поскольку в тот момент мне слишком часто приходили запросы - у нас менеджер увольняется - поднимите всю его переписку за несколько лет. А там сотни тысяч файлов в eml-формате в двух папках. Входящие и исходящие, на другое этот почтовый сервер тогда был не готов. А так индекс - месячные архивы разложенные по папкам. Задаешь параметры поиска и оставляешь на пару суток для извлечения.
А squashfs вообще readonly.
> А дальше тебе к примеру надо изменить файл где-то в середине архива на 20 Gb.Очевилно, сабж сделан в первую очередь для чтения. Но если надо модификации, то он их тоже поддерживает:
https://github.com/mxmlnkn/ratarmount?tab=readme-ov-file#wri...
Причем оно тоже будет быстрее, потому что ты можешь прозрачно для FS накопить изменения (удаления и добвления) ща несколько дней, а потом в конце сделать commit, тем чамым препесоздав архтв единожды, а не на каждый файл.
> Прилепить костыль с отдельным архивом где будут храниться измененные файлы? Индекс это сам по себе костыль.
Я смотрю, ты мастер ментальной акробатики: распаковывает архив - костыль, не распаковывает - костыль, пересоздать архив за раз, а не на каждый файл - тоже костыль. Ты по инерции споришь?
>[оверквотинг удален]
> то он их тоже поддерживает:
> https://github.com/mxmlnkn/ratarmount?tab=readme-ov-file#wri...
> Причем оно тоже будет быстрее, потому что ты можешь прозрачно для FS
> накопить изменения (удаления и добвления) ща несколько дней, а потом в
> конце сделать commit, тем чамым препесоздав архтв единожды, а не на
> каждый файл.
>> Прилепить костыль с отдельным архивом где будут храниться измененные файлы? Индекс это сам по себе костыль.
> Я смотрю, ты мастер ментальной акробатики: распаковывает архив - костыль, не распаковывает
> - костыль, пересоздать архив за раз, а не на каждый файл
> - тоже костыль. Ты по инерции споришь?Все что не задумано как штатная функция - костыль. Очевидно tar не задумывался как архиватор позволяющий менять содержимое архива, и читать его иначе как последовательно. Все остальное - костыли. Костыли могут быть полезные(они помогают людям передвигаться), но это костыли. Человек на костылях рекордов не поставит. Разве что среди других людей на костылях.
Дав каждом языке, не только в питоне есть приложение или библиотека позволяющая монтировать tar через fuse. Или "гулять" по tar параллельно, тем не менее суммарное количество ллей которые ими пользуются гораздо меньше чем tar - узкая специализация этих приложений и заточенность на решение конкретной задачи. Тебе подходит? Повезло.
Как скажешь, эксперт по костылям.
> Как скажешь, эксперт по костылям.Мне не нравится слово эксперт, но "мастер" вполне...
> Все что не задумано как штатная функция - костыль. Очевидно tar не задумывался как архиватор позволяющий менять содержимое архива, и читать его иначе как последовательно. Все остальное - костыли.Надеюсь, ты TAR читаешь сугубо с бобин магнитной ленты? Ведь TAR именно для этого задумывался (оттого и упомянутые тобой особенности), а не для хранения на жестком диске. Хранить его на жестком диске - это такой костыль!
А теперь уже ты "подменяешь", tar писался для работы с лентой. А потом переписали под работу с жестким диском по тем же алгоритмом что и с лентой. более того его даже расширили. там же изначально не было мета-информации просто сплошной поток из файлов. Но это было офигеть как давно. За эти 20 лет много было попыток переизобрести tar с разной степенью у эффективности, но никому пока не удалось вроде как. С чего вдруг это поделие сможет переломить ход истории? Вангую, про него забудут уже примерно через полгода. Еще года три здесь будут появляться новости. ИМХО чтобы создать действительно что-то действенное, нужно выйти за рамки tar. Нужно как в rar или 7z составлять списки файлов добавлять контрольные суммы, указатели на файлы и информацию для восстановления. надо где-то хранить мета-информацию, надо иметь эффективный способ менять архив частями не распаковывая его полностью, а только частично... и т. д. и т. п. Но точно не в контейнере с tar.
> ИМХО чтобы создать действительно что-то действенное, нужно выйти за рамки tar.Но сохранить обратную совместимость с аргументами cli. А то изобретатели велосипедов любят выдумывать всё с нуля. Я как-то пытался пользоваться какой-то "современной альтернативой", кажется это был dar. У него был какой-то упоротый мануал, но в итоге что-то напутав в командной строке оно мне тупо затёрло файлы на диске, которые я хотел заархивировать, лол.
tar это контейнер. Как контейнер и дремучий формат zip абсолютно ничем не хуже. Никто не изобретает потому что всем в последнее время на прогресс стало пофигу. Зачем думать когда у нас есть айфон и компания apple которая за всех думает.
> gzip, xz и тому подобные вроде как не требуют декомпрессировать все данные, они сжимают отдельными блоками, насколько помню, поэтому имея индекс, должно быть можно обращаться почти в произвольное место архива.Все правильно, именно так сабж и работает. Но местные уникумы наставили тебе минусов, ибо про solid сжатие они слышали, а про размер словаря - нет.
> tar бы постепенно умерПрежде чем желать ему смерти, умник, попробуй без него сжать gz*/bz*/lz*/zstd/etc директорию с файлами. Узнаешь много нового о сжатии файлов и том, какую роль в нём выполняет tar.
"Им бы понедельники взять да отменить..."
У тебя начало цитаты потерялось:> Мне кажется, если бы другие архиваторы научились бы хранить права на файлы и xattr файловых систем linux, то tar бы постепенно умер.
.
Все подобные утилиты - зло, и удачи вам в открытии архива на несколько гигабайт.> ratarmount для ускорения навигации по архиву заранее индексирует содержимое для эффективного случайного доступа к данным
Угу. По-русски при обращении к архиву он полностью распаковывается (скорее всего, куда-нибудь на винт). Жесть и ад.
Чем подобная утилита отличается от луп-образа udf, особенно при наличии индекса?
>скорее всего, куда-нибудь на винтЗачем писать то, что можно хранить в памяти?
> удачи вам в открытии архива на несколько гигабайтА что, по вашему, должно пойти не так? Естественно, при первом монтировании он должен прочитать весь TAR.GZ, дабы построить индекс. Но то же самое произойдет и при обычной распаковке.
> По-русски при обращении к архиву он полностью распаковывается (скорее всего, куда-нибудь на винт). Жесть и ад.
Только при первом обращении. И нет не на винт, а на лету.
Со страницы проекта:
Random Access: Care was taken to achieve fast random access inside compressed streams for bzip2, gzip, xz, and zstd and inside TAR files by building indices containing seek points.
Неважно сколько гигабайт, важнее как сильно сжат
На этом можно контейнеры запилить. И похоронить докер.
а в чём заключается необходимость похорон докера? Вас докеры обижают возле дома? Попробуйте познакомиться с podman, containerd и прочими альтернативами. Возможно, они помогут вам победить докеров.
> а в чём заключается необходимость похорон докера?Да забей, персонаж не понимает, что несет.
Отключали эту ерунду в nc, отключали в far, отключали zipfldr.dll аж с win9x, теперь, нидайбох, ещё и в Линуксе...
Чёт у меня не работает ничего... Архив вроде монтируется, но в точке монтирования пусто.
>Данные извлекаются по мере необходимости без предварительной распаковки всего архива.удачи вам поработать с непрерывными архивами - без предварительного извлечения всего куда нибудь в темпы, для чтения одного файла каждый раз будет распаковываться весь архив заново
> для чтения одного файла каждый раз будет распаковываться весь архив зановоВы когда-нибудь научитесь читать новости дальше заголовка?
В первом же параграфе: "Данные извлекаются по мере необходимости без предварительной распаковки всего архива. "
Давай, я угадаю - ты просто не знаешь что такое "непрерывный архив" и как с ними работать даже представления не имеешь?
> ты просто не знаешь что такое "непрерывный архив" и как с ними работать даже представления не имеешьТы наверное знатно удивишься, узнав, что TAR.GZ и прочие TAR.* являются непрерывными архивами чисто по определению.
Может, так будет понятней (с официальной страницы проекта):
Care was taken to achieve fast random access inside compressed streams for bzip2, gzip, xz, and zstd and inside TAR files by building indices containing seek points.
На, читай, неуч:
Непрерывный архив (англ. solid archive) — файловый архив, упакованный таким образом, что все сжимаемые файлы рассматриваются как один непрерывный поток данных. При упаковке каждого файла (кроме первого) используется информация, содержащаяся в предыдущих файлах. В обычных архивах каждый файл сжимается и хранится независимо от других.
Молодец, ты привел в пример буквально описание сути TAR.* архивов. У тебя "смотрю в книгу - вижу фигу"?
Эта новость не альтовцы случаем сюда турнули?
А, то систему griggorii давал уже где то как несколько лет назад и да , там уже это было. А,те только проснулись
*Total commander вошёл в чат*
> *Total commander вошёл в чат*Да это не только Total Commander умел, Krusader тоже может. Это удобно только когда нужно быстро просмотреть содержимое архива. Но монтирование это другое, это позволяет произвольным приложениям иметь доступ к файлам.
Кстати, в KDE была утилита KIO Mount, кажется она тоже может монтировать архивы и многое другое.
чё ты несёшь
Ещё древние египтяне монтировали архивы.
> *Total commander вошёл в чат*К какому месенжеру прикрутил? И чего он туда спамит? :)
у Solus предрелиз Xfce 4.20:
Вот интересно, а почему не делать tar, где первым файлом в /tmp/ идёт индекс этого архива? А в утилитах - проверять , что первый элемент - это архив, проверять соответствие первого элемента всему тарболу, и юзать?
Потому что нафиг такие извращения не нужны.TAR - это буквально про архивацию: раз целиком упаковал, пару раз в год целиком распаковал. А для постоянных модификаций или частичной распаковки есть ZIP и 7Z.
Собственно, поэтому НИКОГДА tar и не использую. Но ведь никто не мешает к чужим архивам приделывать этот заголовок банальной конкатенацией.
> Потому что нафиг такие извращения не нужны.Но и мешать не будут
> Вот интересно, а почему не делать tar, где первым файлом в /tmp/
> идёт индекс этого архива?Вроде в каком-то из (гнутых?) субформатах TAR даже есть как раз опция когда индекс таки - где-то в начале архива - все же пристроить можно. Но то что это все будет в взятом наобум .tar.gz или чем там - ниоткуда не следует.
Посоветуйте, пожалуйста, фс или формат архива с фичей WORM? UDF не работает, не смотря на свой собственный ман.
> Посоветуйте, пожалуйста, фс или формат архива с фичей WORM? UDF не работает,
> не смотря на свой собственный ман.Squashfs тут вон советуют. Оно так то файловая система, так что заодно и монтируется сразу без эвона каких мегакостылищ на питоне и рандомный доступ сразу нормальный.