В чем разница между форматами архивных файлов TAR и CPIO?
Мне любопытно, я немного почитал, но у меня остались вопросы.
Что отличает CPIO от TAR? В другом вопросе мне сказали, что tar предназначен для объединения многих файлов в 1 архив, который обычно является gzip'd или bzip'd.
Также мне сказали, что TAR не может сжимать из STDOUT. Я хочу заархивировать / сжать снимки ZFS для резервного копирования. Мне было интересно, смогу ли я объединить CPIO с bzip2, чтобы получить этот эффект.
Или у меня совершенно неверная идея? Разве это не цель CPIO?
К таким командам я пришел после прочтения, поэтому документы Oracle о резервном копировании снимков ZFS.
# Backup snapshot to cpio and bzip2 archive
zfs send media/mypictures@20070607 | cpio -o | bzip2 -9c > ~/backups/20070607.bz2
# Restore snapshot from cpio and bzip2 archive
zfs recieve media/mypictures@20070607 | cpio -i | bunzip2 -c ~/backups/20070607.bz2
6 ответов
И то и другое 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 или любой другой инструмент сжатия потока, если хотите.)
В дополнение к тому, что было сказано ранее Гравитацией и Полом:
история
В "старые времена", cpio (с опцией -c used) был инструментом, который использовался для перемещения файлов в другие производные UNIX, поскольку он был более переносимым и гибким, чем tar. Но проблемы переносимости смолы можно считать решенными с конца 1980-х годов.
К сожалению, это было примерно в то время, когда -c формат cpio (просто посмотрите страницу руководства для GNU cpio и опцию -H). В то время tar стал более переносимым, чем cpio... Прошло почти целое десятилетие, пока разные производители UNIX не разобрались в этом. Установка GNU tar и 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 указать команду постпроцессора - хотя я бы все же предпочел трубу. Может быть, это полезно при записи на определенные устройства.
Я попросил техническую поддержку HP в ок. 1996 зачем использовать cpio над tar,
Мне сказали, что ленты растягиваются и изнашиваются. когда tar достигает нечитаемой части ленты, выходит из строя и возвращает номер ошибки. когда cpio достигает нечитаемой части, продолжается до следующего читаемого блока, выполняет повторную синхронизацию и продолжается.
Я никогда не видел документацию, подтверждающую это, но всегда использовал cpio,
У 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.
Пока ответы здесь уже сравнивают 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,