On Mon, Oct 14, 2013 at 11:38:13AM -0500, Rob Landley wrote: > On 09/30/2013 10:50:13 PM, [email protected] 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.) There should be 3 versions in the archive: -the first one I sent (this), which was a case of attaching the wrong file -the second one I sent, which was the right file: http://lists.landley.net/pipermail/toybox-landley.net/2013-September/001387.html http://lists.landley.net/pipermail/toybox-landley.net/attachments/20130930/a4c67169/attachment.c -the last update, which fixes an issue with symlinks and special files that we can stat but not read (thereby losing a couple lines of code): http://lists.landley.net/pipermail/toybox-landley.net/2013-October/001408.html http://lists.landley.net/pipermail/toybox-landley.net/attachments/20131012/768acc12/attachment.c > > >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"?
newcrc was supposed to be newc + crc (ie, the c_check field contains a checksum instead of "00000000"). But they messed up and filled it with a count of nonzero bits, which is pretty weak. > > >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 quick way to do that is to increment name until name[0] != '/'. > >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.) That was tcpsvd. > 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. :) OK, it's in LSB. LSB 4.1 says "See SUSv2" http://pubs.opengroup.org/onlinepubs/7908799/xcu/cpio.html Which lists: cpio -o[aBcv] cpio -i[Bcdmrtuvf] [pattern ...] cpio -p[adlmuv] directory cpio -p is a fancy way of doing cp -R, so let's ignore it. That leaves aBcdmrtuvf of those, -a changes atime (why?), -c is a nop or means adding old binary/old character format. -B is blocksize (we'd ignore it), so rf are the meaningful ones beyond what busybox has. Busybox has the "<n> blocks" and also implements -dmvuF. -F is if (TT.fname) { close(toys.optflags & (FLAG_i|FLAG_t) ? 0 : 1); xopen(TT.fname, TT.optflags & FLAG_o ? O_CREAT|O_WRONLY|O_TRUNC : O_RDONLY); } -d needs the logic from mkdir -p -m would be close to touch -m in logic -v is pretty simple. -u is the current behavior; I'd need to check before creating if it isn't set... > >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... Thanks, Isaac Dunham _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
