On 5/11/19 5:44 PM, Andy Lutomirski wrote: > I read some of those emails. ISTM that adding TAR support should be > seriously considered. Sure, it's baroque, but it's very, very well > supported, and it does exactly what we need. Which means you now have two parsers supported in parallel forevermore, and are reversing the design decision initially made when this went in without new info. Also, I just did a tar implementation for toybox: It took me a month to debug it (_not_ starting from scratch but from a submission), I only just added sparse file support (because something in the android build was generating a sparse file), there are historical tarballs I know it won't extract (I'm just testing against what the current one produces with the default flags), and I haven't even started on xattr support yet. Instead I was experimenting with corner cases like "S records replace the prefix[] field starting at byte 386 with an offset/length pair array, but prefix[] starts at 345, do those first 41 bytes still function as a prefix and is there any circumstance under which existing tar binaries will populate them? Also, why does every instance of an S record generated by gnu/tar end with a gratuitous length zero segment?" "cpio -H newc" is a _much_ simpler format. And posix no longer specifies _either_ format usefully, hasn't for years. From toybox tar's header comment: * For the command, see * http://pubs.opengroup.org/onlinepubs/007908799/xcu/tar.html * For the modern file format, see * http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06 * https://en.wikipedia.org/wiki/Tar_(computing)#File_format * https://www.gnu.org/software/tar/manual/html_node/Tar-Internals.html And no, that isn't _enough_ information, you still have to "tar | hd" a lot and squint. (There's no current spec, it's pieced together from multiple sources because posix abdicated responsibility for this to Jorg Schilling.) Rob P.S. Yes that gnu/dammit page starts with a "this will be deleted" comment which according to archive.org has been there for over a dozen years. P.P.S. Sadly, if you want an actually standardized standard format where implementations adhere to the standard: IETF RFC 1991 was published in 1996 and remains compatible with files an archivers in service. Or we could stick with cpio and make minor changes to it, since we have to remain backwards compatible with it _anyway_....
