この質問はかなり古いですが、次の情報をもっと早く見つけるのが簡単だったらよかったのにと思います。他の誰かがこれに出くわしたら、楽しんでください:
上記の Jeff の説明は、gnu tar の既知のバグです (2008 年 8 月に報告されました)。最初のアーカイブのみ (-f の後のもの) オプション) は、その EOF マーカーを削除します。 2 つ以上のアーカイブを連結しようとすると、最後のアーカイブはファイル エンド マーカーの後ろに「隠され」ます。
tar のバグです。末尾のゼロ ブロックを含め、アーカイブ全体を連結するため、デフォルトでは結果のアーカイブの読み取りは最初の連結後に停止します。
ソース:https://lists.gnu.org/archive/html/bug-tar/2008-08/msg00002.html (およびそれに続くメッセージ)
バグの年齢を考えると、修正されるかどうか疑問に思います。影響を受けるクリティカルマスがあるとは思えません。
このバグを回避する最善の方法は、-i を使用することです。 オプション、少なくともファイル システム上の .tar ファイルの場合。
Jeff が指摘するように tar --concatenate 次のアーカイブを連結する前に、EOF に到達するまでに長い時間がかかることがあります。したがって、tar -i を必要とする「壊れた」アーカイブに行き詰まる場合は、 untar するオプションがある場合は、次のことをお勧めします:
代わりに tar --concatenate -f archive1.tar archive2.tar archive3.tar 走ったほうがいいでしょう cat archive2.tar archive3.tar >> archive1.tar または dd にパイプします テープ デバイスに書き込む場合。また、できることにも注意してください。 新しいデータをテープに (上書き) 書き込む前にテープをゼロにしないと、予期しない動作が発生します。そのため、質問の下のコメントで提案されているように、アプリケーションで採用しようとしているアプローチはネストされた tar です。
上記の提案は、次の非常に小さなサンプル ベンチマークに基づいています:
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
buffer.*.tar ファイルのサイズはすべて 100GB で、システムは各呼び出しを除いてほとんどアイドル状態でした。この時間差は、サンプル サイズが小さいにもかかわらず、このベンチマークが有効であると個人的に考えるほど重要ですが、これについては自由に判断してください。おそらく、このようなベンチマークを自分のハードウェアで実行することをお勧めします。
これは役に立たないかもしれませんが、-i を使用したい場合は 最終的なアーカイブから抽出するときにオプションを使用すると、単純に cat できます tar ファイルは、ヌルでいっぱいのヘッダーで終わり、レコードの終わりまでヌル パディングが追加されます。 --concatenate で tar は、すべてのヘッダーを調べて、最終ヘッダーの正確な位置を見つけ、そこで上書きを開始する必要があります。
cat だけの場合 タール、ヘッダー間に余分なヌルがあるだけです。 -i オプションは、ヘッダー間のこれらの null を無視するように tar に要求します。
cat receiverTar1.tar receivedTar2.tar ... >>alltars.tar
tar -itvf alltars.tar
また、あなたの tar --concatenate 例が機能するはずです。ただし、複数の tar アーカイブに同じ名前のファイルがある場合、結果の tar からすべてを抽出するときに、そのファイルを何度も書き直すことになります。