> My mistake was trying to combine .tar.gz files using cat. gzip plays ball, but tar throws a strop.
>
> gzip happily combines the compressed members into a single stream, but when tar tries to read the decompressed stream, it finds the first archive’s EOF marker and stops reading.
>
> gzip would be happy to carry on, but tar has given up.
There was no reason to say this three times consecutively. But when an AI wrote the blog post for you then this is the level of quality HN readers have to put up with.
Of course you can tar the original tar.gz files in one pass without extracting anything. You keep the boundaries between the source tar.gz but maybe that's not important. You probably won't gzip the output because there is very little to gain anymore.
But if you want to merge those tar.gz, yes, you have to ungzip them and gzip the final tar. More CPU.
Depending on the effort you’re willing to put in, you don’t have to: gzip has a specific provision for concatenated files and tar is a flat array of (file) records each followed by file data, terminated by a sentinel record, so what you need to do is to trim the sentinel off the first tar.gz and then append the second one as is. I don’t know of a ready-made tool that would be able to chop off a gzip file’s last 512 uncompressed bytes without recompressing it in full, but it ought to be possible.
11 comments
[ 0.26 ms ] story [ 9.7 ms ] thread> My mistake was trying to combine .tar.gz files using cat. gzip plays ball, but tar throws a strop. > > gzip happily combines the compressed members into a single stream, but when tar tries to read the decompressed stream, it finds the first archive’s EOF marker and stops reading. > > gzip would be happy to carry on, but tar has given up.
There was no reason to say this three times consecutively. But when an AI wrote the blog post for you then this is the level of quality HN readers have to put up with.
But if you want to merge those tar.gz, yes, you have to ungzip them and gzip the final tar. More CPU.