ratarmount 1.0.0

Интересно, как это сделано? Он сначала сканирует весь архив и записывает оффсеты блоков? Возможно ли таким образом подмонтировать тарбол по http не скачивая его полностью?

Удаленные протоколы доступа (FTP, HTTP, HTTPS, SFTP, SSH, Git, Github, S3, Samba v2 и v3, Dropbox, ...)

Если эта штука архивы монтирует, то ей нужен доступ по сети?

Типа того

https://github.com/mxmlnkn/ratarmount?tab=readme-ov-file#the-solution

Возможно ли таким образом подмонтировать тарбол по http не скачивая его полностью?

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

Потому, что ленточные накопители еще не умерли :) А он по жизни Tape ARchiver

Потому что рандом доступ к архиву обычно не нужен.

Потому что рандом доступ к архиву обычно не нужен.

Обычно да, но если нужен… Накладные расходы на хранение таблицы смещений минимальны.

Мне кажется можно даже сохранить совместимость с лентами, если дописывать таблицу всегда в конце файла.

Ну zip сам по себе в этом плане не удобен. У его индекс в конце файла и его не удобнопо этому использрвать. Конечно zip имеет потоковые упаковщики и распаковщики, но с кучей огианичений. Для zip я реализовывал http сервер который может как скачать зип с упаковкой налету, так и залить с распаковкой налету. Но т.к в zip чексумма пишется до файла, а не после и zip не позволяет писать размер файла и не записать чексумму, размер файла не пишется и при распаковке длина определяется по окончанию сжатого потока.
А для задач со случайным доступом я использовал iso и squashfs. Эти форматы уже расчитанны под оптимальный рандомный доступ на устройствах с долгим временем запрсоа (cd) и из-за этого остаётся оптимальным и для сети. Не помню как squashfs, но iso может создаваться потоково, сразу записываясь на диск - для этого он считает размеры файлов до создания образа. Со сжатием конечно сложнее т.к ты не знаешь сжатый размер заранее, вероятно squashfs нельзя создать в потоковом режиме.
В любом случае придётся выбирать два из трёх:
Случайный доступ
Потоковое сжатие архива
Сжатие
Есть конечно компромис в виде индекса в конце как у зипа. То есть zip нужно всего лишь сделать возможность указания размера файлов в непотоковом режиме и тогда его можно будет и создавтаь и распаковывать потоково, а не что-то одно. А с zlib-1 сжатием в принципе zip и так может потоковое сжатие + random access, но для random access нужно знать размер файла чтобы заранее считать его конец

Вот там, где нужен (по мнению тех кто пакует), там и используют другие форматы. А там, где ненужен, он ненужен полностью. К тому же рандом доступ несовместим со сквозным gzip.

Русские песали.

Типа dar

disk archiver

один из выходов как в «расширяемом» pdf - оглавление в конце - но если только обновления - получается обратно хронологический список размазанный по всей ленте от конца к началу

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

zip вообще пиндисен не хранит в базовом варианте кодировку имён дерева объектов просто байтовые поля - всё как завещал автор

«все %»№;%:? кроме я"

ну либо индекс один всегда в конце и при дописывании:

зачитали(из последний хаха бит) позицию(либо размер насколько ленту к началу отмотать от текущего конца ) где индекс начинается и сам индекс Индекс

с места Индекса записали обнову

выгрузили Индекс + запись позиции обновы + инфа где_же_индекс

Вот, dar - отличный кандидат. Только он должен стоять по-умолчанию в базовой системе, вместе с bash, grep и tar.

Это хорошо, но хотелось бы что-то стандартное, как tar. Чтобы стояло везде в базовой системе.

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

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

дыкыть пользуйся молотком и зубилом. оно есть везде.
но ты ж с собой таскаешь перфоратор - ибо он на порядок удобнее.

помимо отсуствующего индекса тарпердобола есть еще «тяжелый» вопрос.
как дается доступ к произвольному месту внутри непрерывного сжатого потока (bz2 gz xz или иное не важно).
это непрерывный архив, в середину него просто так не влезешь, в отличии, к примеру, от зип - там пофайловое сжатие (ну и индекс).

непрерывно-блочные методы сжатия есть только в раре и 7зип.

ну эта проблема решаемая, если сделать таблицу опциональной или ограниченной по размеру

Отличная штука, пользуюсь с версии 0.5, после archivemount был прям вау эффект)

Tatarmount

Я когда-то пользовал, было дело. Чем сейчас на ленточные библиотеки пишут понятия не имею.

Его разработка должна вестись сообществом.

Потому что главный конкурент – 7-zip – не сохраняет все линуксовые атрибуты, а жаль.

рар сохраняет, но не всё :)
squashfs вообще ориентировался на линукс. и потому умеет всё линухово
вотъ

Выглядит интересно. А каковы юзкейсы? Это кто-то в жизни пользовал? И зачем?

доступен к установке из pip

Та ну нафиг. Уж лучше посижу на archivemount, благо я его уже интегрировал в vifm + мне не нужно открывать тяжелые архивы.

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

а вот с битым таром - много что можно сделать.

и да - я не понимаю в чём проблема распаковать архив и запаковать обратно в наше время? я понимаю во времена PDP-11 и IBM PC/XT - это представляло проблему. но сейчас-то?

и да - видимо ленты они тоже в жизни не видели )))))

он и не собирался! это типичное поделие под венду

если вы не в курсе, то сообщаю, что NetBackup на ленте физически - это извод тара и есть ;-)

и да - грамотный сериализатор - это самая мякотка при работе с лентами и есть, на этом целый один продукт был построен - CommVault.

и да - просвятите, чем робот вам сериализацию заменит?

это какое-то новое слово в работе с лентами ))))

если что, то с БНМЛ я работал, фактически весь их функционал сводится к управлению перестановкой кассет. утрирую конечно, но намеренно.

Обычно да, но если нужен…

То используется другой формат.

// Ваш К.О.

Придумали проблему - придумали решение.

Реальный сценарий-то какой?

Надо будет заценить. Пока пользуюсь (хоть и изредка) archivemount, и да, он порой тормозной. Если сабж и правда лучше, надо будет переходить.

По описанию похоже на попытку сделать из tar подобие RAR/7Z/ZIP через FUSE.

Но линуксовые атрибуты в tar сохраняются, а сжимаются отдельно, получив в итоге archive.tar.7z. Или я что то не понимаю?

Имхо, мне бы больше понравилось по методу kiss монтировать http файлы, а потом монтировать архивы отдельно. Что-то типо

mount -t http 'http://localhost/archive.tar' /mnt/www/archive.tar
mount -t tar /mnt/www/archive.tar /mnt/archive.tar/

Какой? В том и дело что стандартного архиватора для диска нет. dar - хороший кандидат, но он не стандартный.

Зависит от задач. Но если рандомный доступ к файлам прям критически важен, то я, например, вообще SquashFS использую. Формально это не совсем архиватор, конечно. Но во многом можно и так назвать. Там со свлучаныйм доступом к любым файлам из любого места полный порядок, и zstd поддерживается. И при этом прекрасно можно использовать в качестве архиватора.

Ну а так вообще ещё 7z, например, используют. Без опции solid там сравнительно адекватным это самый рандомный доступ получается.

робот к сериализации действительно отношения не имеет, собственно и как к tar.
робот это не только сериализация, а еще три-четырекуча килограммов системы каталогизации и размещения, прикручивание к которой каменного топора tar просто не имеет смысла.
tar умеет максимум дать команду кожанному мешку поставить следующую кассету. даже не сможет сказать какую откуда и почему :)

CrX, в 7зип в solid режиме есть опция непрерывно-блочного режима, когда solid периодически обрывается и для рандомного доступа к файлу понадобится распаковать всего один блок, который гораздо меньше размера всего архива.

робот это не только сериализация, а … системы каталогизации

гм…вы точно с БНМЛ работали? это точно не про робота!
я то лично с ними неоднократно сталкивался и разными, L500, i3, C4, а также те, к которым в их каморку можно было уже даже можно залезть.
там нет особо никаких мозгов окромя собственно управлением по степеням свободы.

это дело ПО типа уже упомянутого NBU, который ВНЕЗАПНО пользуется форматом тара. естесно, не только им.;-)
про Комволт не помню какой у него

и да, я когда-то делал скрипт где по сути tar и менял кассетки ;-)
команда mt и это вот всё в виде сурового дяди из СБ, давала указания этому кожаному мешку откуда взять и куда потом положить (почему - ему его начальник уже объяснил до того).

поэтому пожалуйста не путайте простой исполнительный механизм с ПО, реально принимающим решения

Тем не менее обычно пытаясь распаковать busybox'овым tar'ом gentoo stage3, натыкаюсь на ошибку чтения из-за того, что распакованный тар не влазит в signed int

Там именно ошибка или варнинг? Такие варнинги gzip может слать, без вреда для результата. Если же именно ошибка то очевидно это баг в busybox-е.

Именно ошибка, read на входе tar фейлится

Если оглавления нет, то тогда его должен создать сервер и выдать. Думаю для такого подхода понадобится поддержка удаленным сервером.