Diese Frage ist ziemlich alt, aber ich wünschte, es wäre für mich einfacher gewesen, die folgenden Informationen früher zu finden. Wenn also noch jemand darüber stolpert, viel Spaß:
Was Jeff oben beschreibt, ist ein bekannter Fehler in gnu tar (gemeldet im August 2008). Nur das erste Archiv (das nach dem -f Option) wird die EOF-Markierung entfernt. Wenn Sie versuchen, mehr als 2 Archive zu verketten, werden die letzten Archive hinter Dateiende-Markierungen "versteckt".
Es ist ein Fehler in tar. Es verkettet ganze Archive, einschließlich nachfolgender Nullblöcke, sodass das Lesen des resultierenden Archivs standardmäßig nach der ersten Verkettung stoppt.
Quelle:https://lists.gnu.org/archive/html/bug-tar/2008-08/msg00002.html (und folgende Meldungen)
Angesichts des Alters des Fehlers frage ich mich, ob er jemals behoben wird. Ich bezweifle, dass es eine kritische Masse gibt, die betroffen ist.
Der beste Weg, diesen Fehler zu umgehen, könnte die Verwendung von -i sein Option, zumindest für .tar-Dateien auf Ihrem Dateisystem.
Wie Jeff auf tar --concatenate hinweist kann lange dauern, bis das EOF erreicht ist, bevor es das nächste Archiv verkettet. Wenn Sie also mit einem "kaputten" Archiv stecken bleiben, benötigen Sie den tar -i Option zum Entpacken schlage ich Folgendes vor:
Anstatt zu verwenden tar --concatenate -f archive1.tar archive2.tar archive3.tar Sie werden wahrscheinlich besser dran sein, zu rennen cat archive2.tar archive3.tar >> archive1.tar oder zu dd leiten wenn Sie beabsichtigen, auf ein Bandgerät zu schreiben. Beachten Sie auch, dass dies könnte zu unerwartetem Verhalten führen, wenn die Bänder nicht genullt wurden, bevor neue Daten darauf (über)geschrieben wurden. Aus diesem Grund werde ich in meiner Bewerbung verschachtelte Tars verwenden, wie in den Kommentaren unter der Frage vorgeschlagen.
Der obige Vorschlag basiert auf dem folgenden sehr kleinen Beispiel-Benchmark:
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
Die buffer.*.tar-Dateien sind alle 100 GB groß, das System war bis auf die einzelnen Anrufe ziemlich im Leerlauf. Der Zeitunterschied ist signifikant genug, dass ich persönlich diesen Benchmark trotz kleiner Stichprobengröße für gültig halte, aber Sie können dies nach eigenem Ermessen beurteilen und sollten einen solchen Benchmark wahrscheinlich am besten auf Ihrer eigenen Hardware ausführen.
Dies hilft Ihnen möglicherweise nicht weiter, aber wenn Sie bereit sind, den -i zu verwenden Option beim Extrahieren aus dem endgültigen Archiv, dann können Sie einfach cat die tars zusammen. Eine tar-Datei endet mit einem Header voller Nullen und mehr Null-Padding bis zum Ende des Datensatzes. Mit --concatenate tar muss alle Header durchgehen, um die exakte Position des letzten Headers zu finden, um dort mit dem Überschreiben zu beginnen.
Wenn Sie nur cat die tars, Sie haben nur zusätzliche Nullen zwischen den Headern. Die -i Die Option weist tar an, diese Nullen zwischen Headern zu ignorieren. Sie können also
cat receiverTar1.tar receivedTar2.tar ... >>alltars.tar
tar -itvf alltars.tar
Außerdem Ihr tar --concatenate Beispiel sollte funktionieren. Wenn Sie jedoch dieselbe benannte Datei in mehreren Tar-Archiven haben, werden Sie diese Datei mehrmals neu schreiben, wenn Sie alles aus dem resultierenden Tar extrahieren.