Cette question est assez ancienne mais j'aurais aimé qu'il soit plus facile pour moi de trouver les informations suivantes plus tôt. Donc, si quelqu'un d'autre tombe dessus, profitez-en :
Ce que Jeff décrit ci-dessus est un bogue connu dans gnu tar (rapporté en août 2008). Seule la première archive (celle après le -f option) voit son marqueur EOF supprimé. Si vous essayez de concaténer plus de 2 archives, la ou les dernières archives seront "cachées" derrière des marqueurs de fin de fichier.
C'est un bogue dans tar. Il concatène des archives entières, y compris les blocs zéro de fin, donc par défaut, la lecture de l'archive résultante s'arrête après la première concaténation.
Source :https://lists.gnu.org/archive/html/bug-tar/2008-08/msg00002.html (et messages suivants)
Vu l'âge du bogue, je me demande s'il sera jamais corrigé. Je doute qu'il y ait une masse critique qui soit touchée.
La meilleure façon de contourner ce bogue pourrait être d'utiliser le -i option, au moins pour les fichiers .tar sur votre système de fichiers.
Comme le souligne Jeff tar --concatenate peut prendre beaucoup de temps pour atteindre l'EOF avant qu'il concatène l'archive suivante. Donc, si vous allez être coincé avec une archive "cassé" qui a besoin du tar -i option pour décompresser, je suggère ce qui suit :
Au lieu d'utiliser tar --concatenate -f archive1.tar archive2.tar archive3.tar vous feriez probablement mieux de courir cat archive2.tar archive3.tar >> archive1.tar ou dirigez-vous vers dd si vous avez l'intention d'écrire sur un périphérique à bande. Notez également que cela pourrait entraîner un comportement inattendu si les bandes n'ont pas été remises à zéro avant d'y (écraser) écrire de nouvelles données. Pour cette raison, l'approche que je vais adopter dans mon application est celle des fichiers tar imbriqués, comme suggéré dans les commentaires sous la question.
La suggestion ci-dessus est basée sur le très petit échantillon de référence suivant :
time tar --concatenate -vf buffer.100025.tar buffer.100026.tar
real 65m33.524s
user 0m7.324s
sys 2m50.399s
time cat buffer.100027.tar >> buffer.100028.tar
real 46m34.101s
user 0m0.853s
sys 1m46.133s
Les fichiers buffer.*.tar ont tous une taille de 100 Go, le système était pratiquement inactif, sauf pour chacun des appels. La différence de temps est suffisamment importante pour que je considère personnellement ce benchmark comme valide malgré la petite taille de l'échantillon, mais vous êtes libre de votre propre jugement à ce sujet et il est probablement préférable d'exécuter un benchmark comme celui-ci sur votre propre matériel.
Cela peut ne pas vous aider, mais si vous êtes prêt à utiliser le -i option lors de l'extraction de l'archive finale, alors vous pouvez simplement cat les goudron ensemble. Un fichier tar se termine par un en-tête plein de valeurs nulles et plus de remplissage nul jusqu'à la fin de l'enregistrement. Avec --concatenate tar doit parcourir tous les en-têtes pour trouver la position exacte de l'en-tête final, afin de commencer à y écraser.
Si vous venez de cat les tars, vous avez juste des nulls supplémentaires entre les en-têtes. Le -i L'option demande à tar d'ignorer ces valeurs nulles entre les en-têtes. Vous pouvez donc
cat receiverTar1.tar receivedTar2.tar ... >>alltars.tar
tar -itvf alltars.tar
Aussi, votre tar --concatenate exemple devrait fonctionner. Cependant, si vous avez le même fichier nommé dans plusieurs archives tar, vous réécrivez ce fichier plusieurs fois lorsque vous extrayez tout du tar résultant.