Tato otázka je poměrně stará, ale přál bych si, aby pro mě bylo snazší najít následující informace dříve. Takže pokud na to ještě někdo narazí, užijte si to:
To, co Jeff popisuje výše, je známá chyba v gnu tar (nahlášená v srpnu 2008). Pouze první archiv (ten za -f volba) odstraní značku EOF. Pokud se pokusíte zřetězit více než 2 archivy, poslední archivy budou „skryty“ za značkami konce souboru.
Je to chyba v dehtu. Zřetězí celé archivy, včetně koncových nulových bloků, takže ve výchozím nastavení se čtení výsledného archivu zastaví po prvním zřetězení.
Zdroj:https://lists.gnu.org/archive/html/bug-tar/2008-08/msg00002.html (a následující zprávy)
Vzhledem ke stáří chyby jsem zvědavý, jestli bude někdy opravena. Pochybuji, že je ovlivněno kritické množství.
Nejlepším způsobem, jak obejít tuto chybu, by mohlo být použití -i možnost, alespoň pro soubory .tar ve vašem systému souborů.
Jak Jeff zdůrazňuje tar --concatenate může trvat dlouho, než dosáhne EOF, než zřetězí další archiv. Pokud tedy zůstanete u „rozbitého“ archivu, který potřebuje tar -i možnost rozbalit tar, navrhuji následující:
Namísto použití tar --concatenate -f archive1.tar archive2.tar archive3.tar pravděpodobně bude lepší běhat cat archive2.tar archive3.tar >> archive1.tar nebo potrubí na dd pokud máte v úmyslu zapisovat na páskové zařízení. Také si uvědomte, že to může vést k neočekávanému chování, pokud se pásky před (pře)psáním nových dat nevynulovaly. Z tohoto důvodu je přístup, který ve své žádosti použiji, vnořené dehty, jak je navrženo v komentářích pod otázkou.
Výše uvedený návrh je založen na následujícím velmi malém vzorovém benchmarku:
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
Všechny soubory buffer.*.tar mají velikost 100 GB, systém byl téměř nečinný, kromě každého z volání. Časový rozdíl je natolik významný, že osobně považuji tento benchmark za platný i přes malou velikost vzorku, ale můžete se o tom svobodně rozhodnout a pravděpodobně bude nejlepší spustit takový benchmark na svém vlastním hardwaru.
Možná vám to nepomůže, ale pokud jste ochotni použít -i možnost při extrahování z finálního archivu, pak můžete jednoduše cat dehty dohromady. Soubor tar končí záhlavím plným null a více null odsazením až do konce záznamu. S --concatenate tar musí projít všemi záhlavími, aby našel přesnou polohu posledního záhlaví, aby tam mohl začít přepisovat.
Pokud stačí cat dehty, máte mezi záhlavími jen další nuly. -i volba žádá tar, aby ignoroval tyto nuly mezi záhlavími. Takže můžete
cat receiverTar1.tar receivedTar2.tar ... >>alltars.tar
tar -itvf alltars.tar
Také vaše tar --concatenate příklad by měl fungovat. Pokud však máte stejný pojmenovaný soubor v několika archivech tar, budete tento soubor několikrát přepisovat, když vše rozbalíte z výsledného taru.