В чем разница между форматами архивных файлов TAR и CPIO?

В дополнение к тому, что было сказано ранее Гравитацией и Полом :

история

В «старые времена», CPIO (с опцией -cиспользуется) был инструмент, чтобы использовать, когда он пришел, чтобы переместить файлы в другие дериваты UNIX, так как это было более портативным и гибким, чем смолы . Но проблемы переносимости смолы можно считать решенными с конца 1980-х годов.

К сожалению, примерно в это время разные поставщики внедрили -cформат cpio (просто посмотрите на страницу руководства по GNU cpio и опцию -H). В то время tar стал более переносимым, чем cpio ... Потребовалось почти целое десятилетие, чтобы разные поставщики UNIX разобрались в этом. Имея GNU дегтя и GNU CPIO установлен было обязательным для всех администраторов, которые должны были иметь дело с лентами из различных источников, тогда (даже в настоящее время я полагаю).

Пользовательский интерфейс

tar может использовать файл конфигурации ленты, где администратор может настроить накопители на магнитной ленте, подключенные к системе. Затем пользователь просто сказал бы: «Ну, я возьму ленточный накопитель 1», вместо того, чтобы запоминать точный узел устройства для ленты (что может быть очень запутанным, а также не стандартизированным на разных платформах UNIX.

Но главное отличие заключается в следующем:

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

cpio архивирует только те файлы или каталоги, к которым оно относится, но не выполняет рекурсивный поиск в подкаталогах. Также cpio получает список элементов, которые будут заархивированы из stdin - поэтому он почти всегда используется в сочетании с find .

Команда cpio часто выглядит пугающе для новичка по сравнению с tar :

 $ find myfiles -depth -print0 | cpio -ovc0 | gzip -7 > myfiles.cpio.gz $ tar czvf myfiles.tar.gz myfiles 

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

Также GNU tar предлагает опцию, -zкоторая заставляет архив сжиматься с помощью GNU zip на лету, что делает вещи еще проще.

С другой стороны, можно делать отличные вещи с помощью команды find & cpio . На самом деле это более UNIX-подобный подход: зачем включать поиск по дереву каталогов в cpio, если уже есть инструмент, который позаботится почти обо всем, что только можно придумать: find . На ум приходят только резервные копии файлов, которые новее определенной даты, ограничение файлов теми, которые находятся в одной файловой системе, или фильтрация поиска-вывода с помощью grep -vисключения определенных файлов ...

Люди из GNU tar потратили много времени на то, чтобы включить те вещи, которые раньше были возможны только с помощью cpio . На самом деле оба инструмента учились друг у друга - но только cpio может читать формат tar - не наоборот.

обработка смолы и выходных данных

Последнее замечание к тому, что вы сказали:

Также мне сказали, что TAR не может сжимать из STDOUT. Я хочу заархивировать / сжать моментальные снимки ZFS для резервного копирования. Мне было интересно, смогу ли я объединить CPIO с bzip2, чтобы получить этот эффект.

Ну, любая версия tar (GNU или нет) может использоваться в конвейере. Просто используйте знак минус ( -) в качестве имени архива:

 $ tar cvf - myfiles | bzip > myfiles.tar.bz 

Также GNU tar предлагает опцию --to-commandдля указания команды постпроцессора - хотя я бы все же предпочел трубу. Может быть, это полезно при записи на определенные устройства.

Оба tarи cpioимеют единственную цель: объединить множество отдельных файлов в один поток. Они не сжимают данные. ( В наши дни tarболее популярным из - за своей относительной простоте - он может принимать входные файлы в качестве аргументов вместо того, чтобы быть вместе с, findкак cpioесть.)

В вашем случае вам не нужен ни один из этих инструментов; они не будут иметь никакого полезного эффекта, потому что у вас не так много отдельных файлов. zfs sendуже сделал то же самое, tarчто сделал бы. Таким образом, у вас нет никаких файлов, только безымянный поток.

Чтобы сжать моментальный снимок, все, что вам нужно сделать, это направить zfsвывод через программу сжатия:

zfs send media/mypictures@20070607 | gzip -c > ~/backups/20070607.gz  gzip -dc ~/backups/20070607.gz | zfs receive media/mypictures@20070607 

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

У tar и cpio, по сути, одна и та же функция, которая заключается в создании единого непрерывного файла из множества файлов и каталогов. Первоначально это было для того, чтобы поместить результат на ленту, но в наши дни он обычно используется для подачи в утилиту сжатия, как вы делали выше. Это связано с тем, что сжатие одного большого файла требует больше времени и пространства, чем сжатие большого количества маленьких файлов. Вы должны заметить, что многие форматы изображений (png, jpg и т. Д.) Уже сильно сжаты и могут даже стать немного больше, если использовать утилиту сжатия.

Ни tar, ни cpio не делают сжатия самостоятельно. Tar эффективно «выиграл» войну «что мы будем использовать для создания совокупных файлов», но cpio может найти его в разных местах. Я не знаю ни о каких преимуществах одного над другим, деготь выигрывает благодаря более частому использованию.

tar действительно может принимать входные данные в stdin и выводить в stdout - который затем будет передан в bzip2, как у вас, или что-то подобное. Если вызывается с параметром «z», он автоматически вызывает gzip на выходе.

Также стоит отметить: на (по крайней мере) FreeBSD и Mac OS X вы можете манипулировать файлами cpio с помощью tar. BSD tar использует libarchive под капотом, поэтому он может обрабатывать cpio, pax, shar ...

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

Я попросил техническую поддержку HP в ок. 1996, почему использование cpioзакончено tar.

Мне сказали, что ленты растягиваются и изнашиваются. При tarдостижении нечитаемой части ленты происходит сбой и возвращается номер ошибки. Когда cpioдостигает нечитаемой части, она переходит к следующему читаемому блоку, выполняет повторную синхронизацию и продолжается.

Я никогда не видел документацию, подтверждающую это, но всегда использовал cpio.

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

find . <predicates> | cpio -pdmv /destination/dir 

Эквивалент с tarбудет включать что-то вроде этого:

find . <predicates> | tar -T - -cf - | (cd /destination/dir; tar xvf -) 

Конечно, есть и другие альтернативы, такие как rsyncи cp --parentsобсуждаемые в другой ветке, но ничто не сравнится с гибкостью, предлагаемой комбинацией findи cpio. Ввиду tarповсеместного создания архивов, это единственная причина, по которой я до сих пор пользуюсь cpio.