On unrelated note, is there any usecase for cpio files other than initramfs? Back in the day rpm2cpio was the recommended way to unpack rpm files, but nowadays rpm2archive is much faster.
However, it's not particularly common practice to stuff a 4gb file into an RPM, so at least at the moment, it's not a very big practical issue.
file Diva.au.pkg/Payload
Payload: gzip compressed data, from Unix, original size modulo 2^32 25391104
gzip -dc Diva.au.pkg/Payload > unpacked file unpacked
unpacked: ASCII cpio archive (pre-SVR4 or odc)
One slide was "we've come up with a new way to install apps! Just run /bin/sh configure, then make, then make install!". After the wave of consternation swept the assembled devs, the next slide was "only joking". With reassurance that you'll still be able to drag an icon to install.
Very amusing to me that CPIO is underneath the pkg install method/format. I wonder what those old school Mac devs would have thought?
tar zcvf tarball.tar.gz -T <(file_name_generator_function_or_process)
echo /etc/hosts | tar zcvf tarball.tar.gz -T-
I noticed when creating container image layers the answer seems to be generally no, but AWS lambda functions with these types of images error with missing directory errors. Is AWS too strict or not?
In practice there are huge incompatibilities between non-standard SVr4 and GNU implementations, but both of them go to great lengths to detect that the format is the other one. And then there are two POSIX/SUS variants that can be easily distinguished from each other (and the SVr4/GNU variants) which are most of what you will see today.
Yeah, most of the ways tar is weird stop seeming weird when you consider the context. It can easily be appended without rewinding the tape to update metadata, it can be read/edited/fixed with just a text editor, it ends with 2 blocks of null bytes because tape doesn't tell you when you hit the end of your data like a file would.
Also, I have a love-hate relationship with the "numbers as octal in ASCII" thing - on the bright side, it avoids questions of endianness;P (Edit: Well, I guess it's big endian...)
curl --silent https://blog.colindou.ch/lets-make-an-os/bad.cpio | hexdump -C | lessWhat to do with CPIO archive that has non-zero c_filesize for directory is an interesting question. It seems to me that it is equally likely that such broken CPIO archive has c_filedata really empty and that it contains actual mostly meaningless data in there (most likely series of struct dirents in some format as returned by calling read(2) on directory).
pax's cpio supports[0]:
- bcpio - Old binary cpio format. Selected by −6.
- cpio - Old octal character cpio format. Selected by −c.
- sv4cpio - SVR4 hex cpio format.
- sv4crc - SVR4 hex cpio format with checksums. This is the default format for creating new archives.
GNU cpio supports[1]:
- binary
- old ASCII [hex?]
- new ASCII
- crc
- HPUX binary
- HPUX old ASCII
0. http://www.mirbsd.org/MirOS/cats/mir/cpio/cpio-20200904.pdf