en essayant d’extraire un fichier tar.gz dans le terminal ubuntu, une erreur s’est produite dans la dernière phrase la voici: tar: Un bloc zéro à 343398
quelle est la solution à ce problème ???
Cela dépend si cela se produit avec tous les fichiers tar.gz
ou seulement avec celui-ci. Ce fichier particulier pourrait être corrompu et ne s'ouvrira donc pas correctement. Si vous utilisez tar pour extraire l'arborescence, vous devez utiliser l'option z
, comme c'est nécessaire lorsqu'une archive est gzippée: tar xzvf <file.tar.gz>
. Sinon, il vaut également la peine d'essayer de l'extraire avec gunzip <file.tar.gz>
Pour savoir si le fichier est corrompu, exécutez gzip -t <file.tar.gz>
; Cette commande vérifie si le fichier contient des erreurs et, le cas échéant, celles-ci doivent apparaître dans le terminal. Cela devrait vous dire si le fichier est corrompu.
Si le fichier est sain et que l'erreur se reproduit, cela signifie probablement que c'est le problème connu avec tar qui se produit lorsqu'un fichier ne comporte pas une paire de zero blocks
à la fin, comme le prévoit GNU tar. La solution consiste à ajouter l'option -i
pour ignorer le zero blocks
. Donc, utilisez tar ixzvf <file.tar.gz>
Le problème est documenté ici en détail.
La même chose m’est arrivée car j’ai passé les deux canaux stdout et stderr via un canal qui ne sépare pas stderr et stdout (une session de terminal Android adb).
De cette façon, certains messages d'erreur ont fini dans le flux. C'était la commande défectueuse:
Commande défectueuse, adb Shell ne fait que fusionner stderr et stdout localement => garbage! :adb Shell tar -cf - /some/dir \| uuencode bla | uudecode -o - > backup.tar
Commande fixe:adb Shell tar -cf - /some/dir 2>/dev/null\| uuencode bla | uudecode -o - > backup.tar
La même chose se produira si vous exécutez une commande similaire sur SSH, comme cette diffusion rapide de tar au-dessus de ssh, si vous oubliez de rediriger stderr vers/dev/null:
ssh user@Host tar -czf /some/remote/path 2\>/dev/null > /local/path/to/file.tar.gz