[Toybox] [New toy] rudimentary cpio version...

[Rob Landley]

On 09/30/2013 10:50:13 PM, ibid.ag at gmail.com wrote:
> I've finally gotten 'cpio' into a shape where it could be useable.

And I've finally gotten through my email to the point you submitted  
this. (I see an update from the web archive, I can check that in as a  
delta against this.)

> This version can archive and extract directories, sockets, FIFOs,  
> devices,
> symlinks, and regular files.
> Supported options are -iot, -H FMT (which is a dummy right now).

I want to tweak the help text but will hold off until I catch up to the  
newer message about this...

> It only writes newc, and could read newc or newcrc.

What's "newcrc"?

> This does NOT implement -d, which essentially is equivalent to
> mkdir -p $(dirname $FILE)
> for every file that needs it.

Let's see, the examples I gave in ramfs-rootfs-initramfs.txt are:

   cpio -i -d -H newc -F initramfs_data.cpio --no-absolute-filenames

   find . | cpio -o -H newc | gzip

It would be nice to get that example working, although...  
--no-absolute-filenames? really? There's no short for that? (I expect  
just NEVER doing absolute filenames is the right thing, and if you  
_want_ that you cd to the root directory yourself and extract it from  
there...)

The aboriginal cpio generator uses the get_init_cpio.c out of the  
kernel (which parses the output of gen_initramfs_list.sh), so that's  
not using cpio directly at all. It'd be kinda nice if it could, but  
that would involve parsing a text file format.

> Hard links are not supported, though it would be easy to add them  
> given
> a hash table or something like that.

I've been thinking of doing that for tar and cp and such, and somebody  
submitted code that was doing something like that already... (Sigh,  
pending is getting overwhelming, I don't remember where.)

My first guess at this is to do a simple linked list (scales well to a  
couple thousand entries) and then upgrade it to a balanced binary tree  
of some kind later. (Hash tables tend to need manual tuning for good  
performance, hash function and number of buckets and so on.)

But for right now we can leave it as a todo item.

> I also have not implemented the "<n> blocks" output on stderr.
> If desired, I can add it pretty simply.

Sigh. Is there any sort of spec on this? SUSv4 utilities doesn't list  
cpio or tar, and  
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html is a  
"Jorg Schilling is on the posix committee" level Solaris disaster.

I'd guess it's desirable, though. (This might be a place where looking  
at the busybox --help output is justified to see what subset they  
chose. :)

> There is one assumption this makes: that the mode of a file, as  
> mode_t,
> is bitwise equivalent to the mode as defined for the cpio format.
> This is true of Linux, but is not mandated by POSIX.

Posix does actually mandate an octal representation for mode bits, as a  
table in the chmod command line description:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html

It doesn't say the OS has to use those _internally_, but everybody does  
because unix version 7 circa 1975 did.

Merged it in pending here, trying to catch up on email...

Rob
 1381768693.0