Codice di errore 141 con tar

Question

tar -xvzf $ filename.tar.gz || {Exit $ ?; }

Ecco i miei script sarebbe uscire con errorCode 141. Sto usando Fedora Core 6 con la versione 1.15 tar

E 'abitudine accade tutto il tempo, ma oltre il 70 per cento del tempo non riesce.

Answer 1

Per risolvere il problema ora stiamo usando cpio per l'archiviazione, che funziona bene per noi ora, anche se vorrei sapere perché tar sta causando questo problema, il suo giro per lungo tempo, e di essere utilizzato come strumento standard per anni.

Answer 2

Mi rendo conto che questa discussione è più di un paio di anni, ma sto commentando per quelle persone che inciampano su questa discussione con l'errore.

Ogni volta che si utilizza l'opzione di compressione, tar apre implicitamente un collegamento con il programma sottostante con un tubo. Così, nel PO Esempio: tar -xvzf $filename.tar.gz, ciò che il catrame sarà effettivamente fare è eseguire qualcosa di simile a questo: gunzip $filename.tar.gz | tar -xv -. È possibile verificare ciò eseguendo un top, dove vedrete due processi (uno per il catrame e uno per gzip).

A volte, però, la pipeline si rompe. Per esempio, se il file non è un file gzip. Prendete per esempio questo: tar -xvzf somefile.iso, che sarebbe equivalente a gunzip somefile.iso | tar -xv -. In una tale situazione, gzip errore fuori. Quando gzip errori fuori, la pipeline si romperà. Un'altra possibilità sarebbe se il file gzip era corretta, ma il file tar all'interno di esso era corrotto. In questo caso, gzip inizia a inviare il flusso non compresso a tar, ma poi si rende conto di catrame qualcosa non va e chiude il flusso. gzip qui sarebbe poi errore fuori, perché è uscita è chiusa.

In valori di uscita, un valore superiore a 128 indica risoluzione a causa di un segnale, e la quantità è superiore a 128 significa che il segnale causato la terminazione. Quindi, se sottraiamo 128 dal codice di uscita del PO di 141, otteniamo 13, che corrisponde alla SIGPIPE (man 7 signal per una lista di segnali standard e dei loro valori interi corrispondenti).

La pagina man elenca commento di SIGPIPE come "pipe rotto: scrivere a tubo con nessun lettori". Allora, sembrerebbe che gzip sta cercando di scrivere al tubo, ma il catrame è più in attesa. La mia ipotesi è che gzip è decomprimere il file con successo, ma il flusso non compresso non è un archivio tar valida. Il mio consiglio sarebbe di eseguire gunzip sul file, quindi eseguire tar sul file dei risultati e vedere che uno non riesce (in base alla SIGPIPE, la mia ipotesi è che il catrame fallirà). In entrambi i casi, sembra che il file non è leggibile da queste versioni degli strumenti (o di corruzione o di un conflitto di versione di qualche tipo).

Come questi file sono stati fatti (quali opzioni di catrame, ecc)? Sono creati su questa macchina o un'altra macchina? Se si crea un file .tar.gz su questa macchina, può questo stessa macchina estrarre i file senza l'errore?

Answer 3

GNU tar restituisce solo un paio di cose, nessuno dei quali è -141. tuttavia, se è in esecuzione un sottoprocesso, come gzip, e quel processo termina in modo anomalo, restituisce che codice di ritorno.

Non sono sicuro di quello che il sottoprocesso avrebbe potuto essere però. provare con --verbose e vedere se si ottiene qualche indizio.