| 1.2, BrainFucker (ok), 20:28, 08/11/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Хм, круто, интересно как шустро работает, а то я последнее время в качестве архивов просто стал использовать squashfs со встроенным сжатием.
| | |
| |
| |
| 3.10, BrainFucker (ok), 20:45, 08/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
Неудобная утилита создания образов по сравнению с tar. Приходится использовать костыль 'tar | tar2sqfs'.
| | |
| |
| 4.27, Аноним (27), 22:25, 08/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Неудобная утилита создания образов по сравнению с tar. Приходится использовать
> костыль 'tar | tar2sqfs'.
Так alias'ом это и заколотить...
| | |
|
| 3.32, Аноним (32), 22:58, 08/11/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Дурацкий вопрос.
Тем что не позволяет, блин, монтировать уже существующий огромный rar–архив как файловую систему. А это питоноподелие — позволяет. И позволяет достаточно шустро с ним работать.
| | |
|
| 2.11, Megacock (ok), 20:47, 08/11/2024 [^] [^^] [^^^] [ответить]
| –3 +/– |
 А что? Есть какой-то иной способ погулять по tar.gz или по tar.bz2 кроме, как сперва распаковать tar ? чудес не бывает. по крайней мере с этими архивами она будет работать очень медленно и требовать место для распаковки. и чтобы проиндексировать содержимое надо будет как минимум прогуляться по всему tar. Там нет готового списка. С остальными может и проще. Но это очередной комбайн. ПО написанное под конкретную задачу с этим справится быстрее. Что только не делают админы чтобы не учить программирование.
Мне кажется, если бы другие архиваторы научились бы хранить права на файлы и xattr файловых систем linux, то tar бы постепенно умер.В прочем, и у других архиваторов хватает своих заморочек. Вангую, разработчики слепили некую как им кажется убервафлю, которая в нужном им направлении справляется лучше чем другие приложения, но когда дойдет до широкого использования, то скорее всего не быстрее а очень даже наоборот. Плюс python со всеми его версиями и зависимости, не только лишь все справятся с установкой, так что широкого распространения не получит.
| | |
| |
| 3.14, Аноним (14), 21:06, 08/11/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> по крайней мере с этими архивами она будет работать очень медленно и требовать место для распаковки
Будет как раз быстро. В этом кау бы и суть проекта, не? Место для распаковки не нужно - при построении индекса она происходит на лету.
> Но это очередной комбайн. ПО написанное под конкретную задачу с этим справится быстрее.
Это и есть ПО, написанное под конкретную задачу - монтирование архивов в 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.
| | |
| 3.15, BrainFucker (ok), 21:09, 08/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
По-моему, распаковывать архив совсем не нужно, его достаточно прочитать для составления индекса на лету, который можно сохранить в кеше на диске, а дальше уже по индексу обращаться в конкретные места архива за файлами на лету. gzip, xz и тому подобные вроде как не требуют декомпрессировать все данные, они сжимают отдельными блоками, насколько помню, поэтому имея индекс, должно быть можно обращаться почти в произвольное место архива.
| | |
| |
| 4.17, Megacock (ok), 21:25, 08/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
А дальше тебе к примеру надо изменить файл где-то в середине архива на 20 Gb. Как это сделать? Прилепить костыль с отдельным архивом где будут храниться измененные файлы? Индекс это сам по себе костыль. Я примерно так же писал в свое время ПО для архивации почты Mdaemon, где в sqlite записывал индекс файлов в архиве, от кого/ к кому/дата/тема/"имя файла в архиве", поскольку в тот момент мне слишком часто приходили запросы - у нас менеджер увольняется - поднимите всю его переписку за несколько лет. А там сотни тысяч файлов в eml-формате в двух папках. Входящие и исходящие, на другое этот почтовый сервер тогда был не готов. А так индекс - месячные архивы разложенные по папкам. Задаешь параметры поиска и оставляешь на пару суток для извлечения.
| | |
| |
| 5.20, Аноним (20), 21:37, 08/11/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А дальше тебе к примеру надо изменить файл где-то в середине архива на 20 Gb.
Очевилно, сабж сделан в первую очередь для чтения. Но если надо модификации, то он их тоже поддерживает:
https://github.com/mxmlnkn/ratarmount?tab=readme-ov-file#writable-mounting
Причем оно тоже будет быстрее, потому что ты можешь прозрачно для FS накопить изменения (удаления и добвления) ща несколько дней, а потом в конце сделать commit, тем чамым препесоздав архтв единожды, а не на каждый файл.
> Прилепить костыль с отдельным архивом где будут храниться измененные файлы? Индекс это сам по себе костыль.
Я смотрю, ты мастер ментальной акробатики: распаковывает архив - костыль, не распаковывает - костыль, пересоздать архив за раз, а не на каждый файл - тоже костыль. Ты по инерции споришь?
| | |
| |
| 6.22, Megacock (ok), 22:04, 08/11/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
>[оверквотинг удален]
> то он их тоже поддерживает:
> https://github.com/mxmlnkn/ratarmount?tab=readme-ov-file#writable-mounting
> Причем оно тоже будет быстрее, потому что ты можешь прозрачно для FS
> накопить изменения (удаления и добвления) ща несколько дней, а потом в
> конце сделать commit, тем чамым препесоздав архтв единожды, а не на
> каждый файл.
>> Прилепить костыль с отдельным архивом где будут храниться измененные файлы? Индекс это сам по себе костыль.
> Я смотрю, ты мастер ментальной акробатики: распаковывает архив - костыль, не распаковывает
> - костыль, пересоздать архив за раз, а не на каждый файл
> - тоже костыль. Ты по инерции споришь?
Все что не задумано как штатная функция - костыль. Очевидно tar не задумывался как архиватор позволяющий менять содержимое архива, и читать его иначе как последовательно. Все остальное - костыли. Костыли могут быть полезные(они помогают людям передвигаться), но это костыли. Человек на костылях рекордов не поставит. Разве что среди других людей на костылях.
Дав каждом языке, не только в питоне есть приложение или библиотека позволяющая монтировать tar через fuse. Или "гулять" по tar параллельно, тем не менее суммарное количество ллей которые ими пользуются гораздо меньше чем tar - узкая специализация этих приложений и заточенность на решение конкретной задачи. Тебе подходит? Повезло.
| | |
| |
| 7.28, Аноним (14), 22:25, 08/11/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Все что не задумано как штатная функция - костыль. Очевидно tar не задумывался как архиватор позволяющий менять содержимое архива, и читать его иначе как последовательно. Все остальное - костыли.
Надеюсь, ты TAR читаешь сугубо с бобин магнитной ленты? Ведь TAR именно для этого задумывался (оттого и упомянутые тобой особенности), а не для хранения на жестком диске. Хранить его на жестком диске - это такой костыль!
| | |
|
|
|
|
|
|
| 1.3, Аноним (3), 20:29, 08/11/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Все подобные утилиты - зло, и удачи вам в открытии архива на несколько гигабайт.
> ratarmount для ускорения навигации по архиву заранее индексирует содержимое для эффективного случайного доступа к данным
Угу. По-русски при обращении к архиву он полностью распаковывается (скорее всего, куда-нибудь на винт). Жесть и ад.
| | |
| |
| 2.7, Аноним (7), 20:34, 08/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
Чем подобная утилита отличается от луп-образа udf, особенно при наличии индекса?
>скорее всего, куда-нибудь на винт
Зачем писать то, что можно хранить в памяти?
| | |
| 2.12, Аноним (14), 20:54, 08/11/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> удачи вам в открытии архива на несколько гигабайт
А что, по вашему, должно пойти не так? Естественно, при первом монтировании он должен прочитать весь 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.
| | |
|
| |
| 2.9, Аноним (9), 20:44, 08/11/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
а в чём заключается необходимость похорон докера? Вас докеры обижают возле дома? Попробуйте познакомиться с podman, containerd и прочими альтернативами. Возможно, они помогут вам победить докеров.
| | |
| |
| 3.13, Аноним (14), 20:55, 08/11/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> а в чём заключается необходимость похорон докера?
Да забей, персонаж не понимает, что несет.
| | |
|
|
| 1.8, InuYasha (??), 20:38, 08/11/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Отключали эту ерунду в nc, отключали в far, отключали zipfldr.dll аж с win9x, теперь, нидайбох, ещё и в Линуксе...
| | |
| 1.16, Аноним (6), 21:19, 08/11/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Чёт у меня не работает ничего... Архив вроде монтируется, но в точке монтирования пусто.
| | |
| 1.19, Аноним (19), 21:28, 08/11/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
>Данные извлекаются по мере необходимости без предварительной распаковки всего архива.
удачи вам поработать с непрерывными архивами - без предварительного извлечения всего куда нибудь в темпы, для чтения одного файла каждый раз будет распаковываться весь архив заново
| | |
| |
| 2.21, Аноним (20), 21:43, 08/11/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> для чтения одного файла каждый раз будет распаковываться весь архив заново
Вы когда-нибудь научитесь читать новости дальше заголовка?
В первом же параграфе: "Данные извлекаются по мере необходимости без предварительной распаковки всего архива. "
| | |
| |
| 3.34, Аноним (19), 01:08, 09/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
Давай, я угадаю - ты просто не знаешь что такое "непрерывный архив" и как с ними работать даже представления не имеешь?
| | |
|
|
|
