Esta pregunta es bastante antigua, pero desearía que hubiera sido más fácil para mí encontrar la siguiente información antes. Entonces, si alguien más se topa con esto, disfrute:
Lo que Jeff describe arriba es un error conocido en gnu tar (informado en agosto de 2008). Solo el primer archivo (el que sigue al -f opción) obtiene su marcador EOF eliminado. Si intenta concatenar más de 2 archivos, los últimos archivos estarán "ocultos" detrás de los marcadores de fin de archivo.
Es un error en el alquitrán. Concatena archivos completos, incluidos los bloques cero finales, por lo que, de forma predeterminada, la lectura del archivo resultante se detiene después de la primera concatenación.
Fuente:https://lists.gnu.org/archive/html/bug-tar/2008-08/msg00002.html (y mensajes siguientes)
Teniendo en cuenta la antigüedad del error, me pregunto si alguna vez se solucionará. Dudo que haya una masa crítica afectada.
La mejor manera de eludir este error podría ser usar el -i opción, al menos para archivos .tar en su sistema de archivos.
Como señala Jeff tar --concatenate puede llevar mucho tiempo llegar al EOF antes de concatenar el siguiente archivo. Entonces, si se va a quedar atrapado con un archivo "roto" que necesita el tar -i opción de descomprimir, sugiero lo siguiente:
En lugar de usar tar --concatenate -f archive1.tar archive2.tar archive3.tar probablemente será mejor que corras cat archive2.tar archive3.tar >> archive1.tar o tubería a dd si pretende escribir en un dispositivo de cinta. También tenga en cuenta que esto podría conducir a un comportamiento inesperado si las cintas no se pusieron a cero antes de (sobre) escribir nuevos datos en ellas. Por esa razón, el enfoque que voy a tomar en mi aplicación es tar anidado como se sugiere en los comentarios debajo de la pregunta.
La sugerencia anterior se basa en el siguiente punto de referencia de muestra muy pequeño:
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
Los archivos buffer.*.tar tienen un tamaño de 100 GB, el sistema estaba prácticamente inactivo excepto por cada una de las llamadas. La diferencia de tiempo es lo suficientemente significativa como para que considero que este punto de referencia es válido a pesar del pequeño tamaño de la muestra, pero eres libre de decidir sobre esto y probablemente sea mejor que ejecutes un punto de referencia como este en tu propio hardware.
Puede que esto no te ayude, pero si estás dispuesto a usar el -i opción al extraer del archivo final, simplemente puede cat los archivos tar juntos. Un archivo tar termina con un encabezado lleno de valores nulos y más relleno nulo hasta el final del registro. Con --concatenate tar debe pasar por todos los encabezados para encontrar la posición exacta del encabezado final, para comenzar a sobrescribir allí.
Si solo cat los alquitranes, solo tiene valores nulos adicionales entre los encabezados. El -i La opción le pide a tar que ignore estos valores nulos entre los encabezados. Entonces puedes
cat receiverTar1.tar receivedTar2.tar ... >>alltars.tar
tar -itvf alltars.tar
Además, su tar --concatenate el ejemplo debería estar funcionando. Sin embargo, si tiene el mismo archivo con el mismo nombre en varios archivos tar, reescribirá ese archivo varias veces cuando extraiga todo del tar resultante.