> 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.
Nothing says "handwritten" quite like omnipresent groups of 3 bullet points, all with bolded item headers.
Yes, this could have been a 5-sentence PSA. I found the article hard to read, with comparatively little content for the length.
Absolutely.
> 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.
useless dashes at the middle of sentences maybe?
Does it actually say anywhere that the article is handwritten?
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.
Even worse with initcpio and linux kernel decompression choices: You can mix them, and it works.. sometimes.
cat is only for concatenation so it won't combine e.g. XML files, images, zip files etc. unless those files can just be splatted together.
which .gz files can, according to the article, but the un-gzipped file contains an eof in the middle for the tape archive, so it stops reading early
Oh! I can cat multiple gzip files? Could I do that with "btrfs send | gzip" files?