Вопросы Теги

Как Вы использовали бы команду cpio?

в Вашем .bashrc:

cpcd() { cp "$1" "$2" && cd "$2"; }

это - то, как я сделал бы это

затем Вы использовали бы cpcd поскольку Вы использовали бы cp

cpcd blah dir/

и это скопирует вздор в dir и если это было успешно, это изменит каталоги на dir /

7
31.01.2014, 08:12
6 ответов

Это все еще важно для распаковки RPMs. Существует a rpm2cpio утилита, которая преобразовывает RPM-пакет в a cpio архив. Насколько я знаю, нет ничего для преобразования об/мин в a tar архив. Вот использование в качестве примера:

rpm2cpio myrpmfile.rpm | cpio -idmv
5
27.01.2020, 20:16
  • 1
    В то время как это верно, это действительно не покрывает основную часть вопроса, спрашивающего, почему cpio лучше, чем tar. Это просто приводит к другому вопросу, почему rpm2tar утилита не существует? Об/мин использует cpio внутренне, раз так почему сделал они предпочли его tar? –  Patrick 31.01.2014, 22:38
  • 2
    частично на основе cpio. Таким образом, rpm2cpio просто делает функцию извлечения, не преобразование. Поэтому существует нет rpm2tar. –  Warren Young 07.02.2014, 09:32

Если Ваша система не имеет tar GNU с -T и - пустая опция cpio путь состоит в том, чтобы получить определенное подмножество файлов в архив tar:

find . -name CVS -prune -o -print0 | cpio -o -Hustar > all.tar

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

Всегда существует использование для нескольких решений той же проблемы. С тех пор cpio может читать tar архивы Вы могли бы также покончить с tar и просто использовать cpio везде.

2
27.01.2020, 20:16
  • 1
    находит, не назвали основное устройство -print0и cpio не может понять вывод от gfind -print0 . –  schily 10.09.2015, 16:58

Я не могу найти единственный сценарий, где cpio был бы лучше, чем более общие инструменты как tar.

Вот один, который я изучил назад прежде rsync и cp -r существовавший:

$ find /foo -print | cpio -pud /bar

Это копирует все файлы в /foo в /bar, сохранение всех полномочий файла и структуры каталогов.

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

1
27.01.2020, 20:16
  • 1
    Не корректный, Вы корректны для исторической реализации tar UNIX, но не для starпоскольку звезда поддерживает - опция копии и может сделать копии, более эффективные, чем cpio. –  schily 10.09.2015, 17:00
  • 2
    @schily: этот вопрос не о звезде, это о tar. OP не открыл дверь в установку сторонних инструментов. –  Warren Young 10.09.2015, 17:03
  • 3
    Из того, что я могу сказать, у каждого системного администратора, который часто использует tar обычно, есть звезда, установленная так или иначе. Если Вы полагаете, что OP использует Linux, то мы должны были бы сильно поощрить пользователей не использовать "cpio" на той платформе как обычно gcpioустановлен как cpio в соответствии с Linux, и gcpio, к сожалению, является реализацией со многими проблемами. –  schily 10.09.2015, 17:23
  • 4
    @schily: Один из нас живет в пузыре, и я вполне уверен, это не я. Я никогда не использовал звезду в веке четверти использования Unix. Это не установлено по умолчанию на RHEL/CentOS, Солярисе, Сервере Ubuntu, FreeBSD или OS X. Это не находится даже на стандартном пакете repo для большинства из тех. Это покрывает огромный блок сегодняшнего центрального системным администратором мира Unix. Между тем Вы записали вещь, поэтому конечно, она установлена на всех Ваших полях. –  Warren Young 10.09.2015, 18:52
  • 5
    Звезда устанавливалась на большинстве дистрибутивов Linux в течение долгого времени, и это - самая старая бесплатная реализация tar. Если Вы не знаете звезду, кажется, что Вы не проверяли на установленные альтернативы в течение прошлых 20 лет. Из-за различных проблем с gtar я избегаю gtar везде, где возможный и многие люди, которые знают, звезда делает то же. Таким образом, это до читателя для решения, кто пузырь. –  schily 10.09.2015, 19:38

tar использует определение архива ustar, которое ограничивает длину пути 100 байтами. Глубоко вложенные иерархии - нисколько не редкий в эти дни - не могут быть заархивированы с tar. cpio не имеет того препятствия.

Я предпочитаю мир (1). Как cpio, мир лучше использует стандартный ввод и вывод, чем tar. мир может использовать cpio формат, что означает, врезаетесь ли Вы в предел пути, можно продолжать использовать ту же утилиту только путем добавления-x cpio к команде. Вы используете ту опцию только для создания архивов; при чтении мира обнаруживает формат автоматически.

1
27.01.2020, 20:16
  • 1
    GNU не имеет такого предела. –  psusi 01.02.2014, 20:23
  • 2
    Предел принадлежит определению формата файла, не утилите. См. char name[100] в документации tar GNU. –  James K. Lowden 20.02.2014, 07:28
  • 3
    Хорошо они обошли его так или иначе, потому что я просто сделал 108 символов названными файлом, и tar обрабатывает его очень хорошо. –  psusi 20.02.2014, 16:29
  • 4
    Не корректный, единственный стандартизированный формат CPIO поддерживает максимальную длину имени файла 255 символов, в то время как стандартизированный формат архива TAR имеет неограниченную длину имени файла. –  schily 10.09.2015, 17:06

Раньше было преимущество использования cpio , но эта особенность не реализована, например, в gcpio. Я говорю о том факте, что исходная реализация AT&T cpio действительно реализовывала извлечение файлов определенным образом, аналогичным тому, что делает install , и это причина, по которой AT&T предпочла использовать cpio для установки двоичных файлов в реальном времени. система.

Если вы вызовете звездочку под именем cpio , вы получите эту функцию и добавите параметр -install к параметрам для звездочки при извлечении файлов возникает такое поведение.

Кстати: формат архива CPIO больше не рассматривается в POSIX как полезный формат, так как он не расширяется. Четыре «варианта» формата CPIO полностью несовместимы друг с другом, и каждый раз, когда требовалось расширение, создавался совершенно новый / несовместимый вариант формата CPIO.

2
27.01.2020, 20:16

Я использовал cpio много лет и до сих пор использую. Это много раз спасало меня при восстановлении без обширных знаний Linux/Unix.

Пример У меня установлен сервер Ubuntu 17.04LTS, и я регулярно обновляю свои файлы для резервного копирования с помощью cpio прибл. ежемесячно с использованием внешнего USB-накопителя 500Gb.

Я монтирую резервный диск как таковой:

mount /dev/sdb1 /BACKUP

Убедитесь, что вы создали папку с именем BACKUP в корневом каталоге в качестве точки монтирования, и используйте следующую команду; 

mount /dev/sdb1 /BACKUP

Выполните df, чтобы убедиться, что он установлен. Затем cd /BACKUPи создайте папку Ubuntu _Backup _17.04LTS.

Затем cd /убедитесь, что вы находитесь в / перед запуском процесса cpio с помощью pwd, а затем выполните следующую команду:

find. -mount -print | cpio -pdumv /BACKUP/Ubuntu_Backup_17.04LTS

При этом будут скопированы все файлы и папки из корневого каталога, ЗА ИСКЛЮЧЕНИЕМ точки монтирования BACKUP.

После завершения, если вы перейдете в /BACKUP/Ubuntu _Backup _17.04LTS и выведете список файлов и папок, вы увидите, что он точно такой же, как и ваш список корневого диска.

Восстановление точно такое же, это может быть полное восстановление просто папки, такой как /etc.

Пример:

cd /BACKUP/Ubuntu_Backup_17.04LTS

и выполните в обратном порядке; 

find. -mount -print | cpio -pdumv /

или для папки /etc )команда будет 

find /etc -mount -print | cpio -pdumv /

Папка /etc будет скопирована из резервной копии в / для восстановления.

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

0
27.01.2020, 20:16

Теги

Похожие вопросы