[Toybox] [PATCH] cpio: support reading concatenated cpio files.

[Rob Landley]

On 4/16/21 1:44 PM, Yi-yo Chiang wrote:
> I'm not sure what Elliot's goal is? I assume he's trying to extract a
> concatenated ramdisk, and I still see a problem in the current solution. 
> 
> The buffer-format
> (https://www.kernel.org/doc/Documentation/early-userspace/buffer-format.txt) says:
> 
>   initramfs  := ("\0" | cpio_archive | cpio_gzip_archive)*
> 
> In other words, both `cat a.cpio b.cpio >merged.cpio` and `(cat a.cpio && echo
> -n -e '\0\0\0' && cat b.cpio) >merged.cpio` are valid initramfs.

It also implies that two compressed files can be concatenated and separated by
arbirary runs of nulls, or you can have a compressed file and a non-compressed
file concatenated, or...

Grrr. I need to test this. And possibly genericize the tar.c code to detect
compression type and run it through a decompressor so cpio can do it too...

> btw gen_init_cpio.c also pads initramfs to 512-byte boundary
> (https://github.com/torvalds/linux/blob/6fbd6cf85a3be127454a1ad58525a3adcf8612ab/usr/gen_init_cpio.c#L97)

*blink* *blink* Why...? (cpio doesn't have a 512 stride in the file format? It
has a 4-byte stride for padding strings with NUL bytes, but that's about it?)

> If we're viewing buffer-format.txt as the "right" cpio spec, then I think we
> should implement this too. We should skip arbitrary extra NUL-bytes padded
> between cpio file frames

Skipping arbitrary extra null bytes at the start is easy enough to do. I guess
the hardwired trailing read was expecting the 512 padding...

I'm gonna need add a _lot_ more test suite entries for this command.

Ok, skip arbitrary leading NUL bytes after each entry, pad last record to 512
byte alignment with NUL bytes, autodetect compression type at each record start,
implement hardlinks and have TRAILER!!! flush hardlink context...

Rob