Код ошибки 141 с tar - PullRequest
       17

Код ошибки 141 с tar

7 голосов
/ 20 апреля 2009

tar -xvzf $ filename.tar.gz || {выход $ ?; }

Здесь мои сценарии завершаются с кодом ошибки 141. Я использую Fedora Core 6 с версией tar 1.15

это не будет происходить все время, но более 70 процентов случаев это терпит неудачу.

Ответы [ 3 ]

19 голосов
/ 14 августа 2013

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

Всякий раз, когда вы используете опцию сжатия, tar неявно открывает соединение с базовой программой, используя канал. Итак, в примере OP: tar -xvzf $filename.tar.gz, что tar сделает на самом деле - это что-то вроде этого: gunzip $filename.tar.gz | tar -xv -. Вы можете проверить это, запустив top, где вы увидите два процесса (один для tar и один для gzip).

Иногда, однако, сам трубопровод разрушается. Например, если файл не является файлом gzip. Возьмем для примера: tar -xvzf somefile.iso, что эквивалентно gunzip somefile.iso | tar -xv -. В такой ситуации gzip выдаст ошибку. Когда ошибки gzip выходят, конвейер сломается. Другая возможность была бы, если бы файл gzip был правильным, но файл tar внутри него был поврежден. В этом случае gzip начинает отправлять несжатый поток в tar, но затем tar обнаруживает, что что-то не так, и закрывает поток. В этом случае gzip выдаст ошибку, потому что его выход закрыт.

В значениях выхода значение выше 128 указывает завершение из-за сигнала, а значение выше 128 указывает, какой сигнал вызвал завершение. Итак, если мы вычтем 128 из кода выхода OP 141, мы получим 13, что соответствует SIGPIPE (man 7 signal для списка стандартных сигналов и их соответствующих целочисленных значений).

Страница man содержит комментарий SIGPIPE как "Сломанная труба: пишите в трубу без читателей". Итак, может показаться, что gzip пытается записать в канал, но tar перестал слушать. Я предполагаю, что gzip успешно распаковывает файл, но несжатый поток не является допустимым архивом tar. Мой совет здесь состоит в том, чтобы запустить gunzip для файла, затем запустить tar для файла результатов и посмотреть, какой из них вышел из строя (основываясь на SIGPIPE, я предполагаю, что tar потерпит неудачу). В любом случае, похоже, что эти версии инструментов не читают файл (либо повреждение, либо какой-либо конфликт версий).

Как создавались эти файлы (какие опции для tar и т. Д.)? Они созданы на этой машине или другой машине? Если вы создадите файл .tar.gz на этом компьютере, сможет ли этот же компьютер извлечь эти файлы без ошибки?

1 голос
/ 20 апреля 2009

GNU tar возвращает только несколько вещей, ни одна из которых не равна -141. однако, если он выполняет подпроцесс, такой как gzip, и этот процесс завершается ненормально, он возвращает этот код возврата.

Я не уверен, что, возможно, был подпроцесс. попробуйте это с --verbose и посмотрите, получите ли вы какие-либо подсказки.

0 голосов
/ 22 апреля 2009

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

...