Упаковать набор файлов в логический «контейнер» - tar или что-то другое

Нет ли более современных альтернатив?

Зачем? Нет. Потому что они не нужны. tar прекрасно справляется со своей задачей.

А то я часто вижу, как обсирают tar ввиду его древности и ненужности.

Ну спроси аргументы, или сразу плюнь в лицо. Скорее всего, аргумент один «но он же придуман давно».

Ты сам вообще как видишь? tar справляется со своей задачей? Если да, то зачем тебе велосипед? Не совсем просто понятна задача. «Упаковать в один контейнер» можно для разный целей. Для произвольного прозрачного доступа быстрого, например, при этом хорошо сжимаемых данных, иногда удобно использовать SquashFS. Один файл с read-only FS, который можно спокойно примонтировать куда угодно.

Озвучь более конкретную задачу в общем.

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

Озвучь более конкретную задачу в общем.

Задача: нужно делать срезы некоторых директорий по датам. Типа резервного копирования, но не совсем (это мои личные заморочки). В общем, нужно просто скормить программе директорию с файлами и получить на выходе один файл. Далее по обстоятельствам сжать его или зашифровать и т.д.

В общем, нужно получить простую сущность - файл. Желательно, чтобы работать с этим файлом можно было максимально быстро. Раньше пользовался tar, а сейчас задумался и решил переспросить на форуме.

Ты сам вообще как видишь? tar справляется со своей задачей?

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

А если с непожатым?

У tar нет заголовка со списком файлов, поэтому доступ к определённому файлу внутри архива занимает O(n): в его поисках нужно просмотреть архив от начала до конца. У архивов, у которых такой заголовок есть (например, dar), доступ к данному файлу занимает 1 seek(), то есть, O(1).

Аналогично с просмотром списка файлов.

Если это для Вас не проблема, продолжайте пользоваться tar.

Dar http://dar.linux.free.fr/

а чего не zip то? и crc считает и пару байтов под свои метки есть и читается очень удобно

Мне далеко не каждый раз нужно сжимать эти контейнеры. Иногда просто упаковать, а иногда сжать и выгрузить куда-то.

Тем более, я часто ловил глюки в zip архивах (паковал не я) - неверная структура каталогов и битые имена файлов.

Задача ясна. Ну да, tar для этого и юзают. Хоть так храни, хоть пожми потом, хоть пожми да зашифруй. .tar.xz.gpg — вполне норм. Если не стоит задача быстрого случайного доступа к произвольным файлам в каждом таком контейнере, а именно в основном целиком.

В zip можно хранить и непожатые файлы.

Буду знать.

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

Вообще задача такая стоит. Но я не могу понять следующего. Все говорят, что tar не делает индекс архива и даже для просмотра списка файлов его нужно полностью распаковать. Только что запаковал в tar директорию с 17 Гб фото. Открываю tar Ark'ом и мгновенно вижу структуру каталогов. Любой файл тоже моментально распаковывается.

Как мне увидеть тормоза? Очень большой архив? Или очень большое дерево каталогов?

Как мне увидеть тормоза?

Сожми этот tar, даже gzip'ом ;)

Или положи его на дешёвую китайскую флешку.

Ох, и правда тормозит))

То есть или не сжимать и пользоваться tar, или переходить на SquashFS, 7z, dar?

То есть или не сжимать и пользоваться tar, или переходить на SquashFS, 7z, dar?

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

Понял. В общем, решать все вопросы одним инструментом - слишком грубо.

Btrfs

в его поисках нужно просмотреть архив от начала до конца.

Это только если оно на ленте. И то, даже на ленте seek выполняется быстрее, чем чтение.