Questa domanda è piuttosto vecchia, ma vorrei che fosse stato più facile per me trovare prima le seguenti informazioni. Quindi, se qualcun altro si imbatte in questo, divertiti:
Ciò che Jeff descrive sopra è un bug noto in gnu tar (riportato nell'agosto 2008). Solo il primo archivio (quello dopo il -f opzione) viene rimosso il suo segnalino EOF. Se provi a concatenare più di 2 archivi, gli ultimi archivi verranno "nascosti" dietro i marcatori di fine file.
È un bug in tar. Concatena interi archivi, inclusi i blocchi zero finali, quindi per impostazione predefinita la lettura dell'archivio risultante si interrompe dopo la prima concatenazione.
Fonte:https://lists.gnu.org/archive/html/bug-tar/2008-08/msg00002.html (e messaggi successivi)
Considerando l'età del bug, mi chiedo se verrà mai risolto. Dubito che ci sia una massa critica che ne risente.
Il modo migliore per aggirare questo bug potrebbe essere usare il -i opzione, almeno per i file .tar sul tuo file system.
Come sottolinea Jeff tar --concatenate può impiegare molto tempo per raggiungere l'EOF prima di concatenare l'archivio successivo. Quindi, se rimarrai bloccato con un archivio "rotto" che richiede il tar -i opzione per decomprimere, suggerisco quanto segue:
Invece di usare tar --concatenate -f archive1.tar archive2.tar archive3.tar farai probabilmente meglio a correre cat archive2.tar archive3.tar >> archive1.tar o pipe a dd se intendi scrivere su un dispositivo a nastro. Nota anche che questo potrebbe portare a un comportamento imprevisto se i nastri non sono stati azzerati prima (sovra)scrittura di nuovi dati su di essi. Per questo motivo l'approccio che adotterò nella mia applicazione è tar annidato come suggerito nei commenti sotto la domanda.
Il suggerimento di cui sopra si basa sul seguente benchmark di esempio molto piccolo:
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
I file buffer.*.tar hanno tutti una dimensione di 100 GB, il sistema era praticamente inattivo tranne che per ciascuna delle chiamate. La differenza di fuso orario è abbastanza significativa che personalmente considero questo benchmark valido nonostante le dimensioni ridotte del campione, ma sei libero di giudicare e probabilmente è meglio eseguire un benchmark come questo sul tuo hardware.
Questo potrebbe non aiutarti, ma se sei disposto a utilizzare il -i opzione durante l'estrazione dall'archivio finale, allora puoi semplicemente cat i tars insieme. Un file tar termina con un'intestazione piena di valori nulli e altro riempimento nullo fino alla fine del record. Con --concatenate tar deve esaminare tutte le intestazioni per trovare la posizione esatta dell'intestazione finale, in modo da iniziare a sovrascrivere lì.
Se solo cat i tar, hai solo null extra tra le intestazioni. Il -i L'opzione chiede a tar di ignorare questi null tra le intestazioni. Quindi puoi
cat receiverTar1.tar receivedTar2.tar ... >>alltars.tar
tar -itvf alltars.tar
Inoltre, il tuo tar --concatenate esempio dovrebbe funzionare. Tuttavia, se hai lo stesso file con lo stesso nome in diversi archivi tar, dovrai riscrivere quel file più volte quando estrai tutto dal tar risultante.