On Oct 13, 2014, at 10:38 AM, Magnus Holmgren <holmg...@debian.org> wrote:
> The > difference is that "ustar" is followed by two spaces, whereas in tar files > created by libtar it's followed by a null character. The history behind this may help make it clearer: There has been a POSIX standard for the tar file format since 1996. It used to be part of the specification for the tar command-line program, but the file format is now part of the specification for the pax command-line program: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06 That standard specifies a 6-byte “magic” field containing “ustar\0” followed by a 2-byte version field containing the ASCII characters “00” (zero zero). These 8 bytes together are the canonical test for POSIX-compliant tar headers. GNU tar is derived from pdtar which predated the POSIX standard. Instead of a 6-byte field followed by a 2-byte field, pdtar used a single 8-byte field containing “ustar\x20\x20\0”. (I presume the author of pdtar got this from an early draft of the POSIX standard but I don’t know that for sure.) Checking these 8 bytes provides a good test for GNU tar format headers vs. POSIX-standard ustar format headers. Note that GNU tar can now generate POSIX-compliant ustar archives or pax extended format archives (with suitable options), so it’s important to distinguish the formats, not the programs. And yes, there are definitely plenty of tar programs that write tar archives that are not compliant with either of these (which is probably why that option exists, to suppress the format check for non-standard tar archives). I wrote a tar.5 man page to document my research into this: http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5 It documents a lot of different tar variations and includes some discussion of how to distinguish them. Cheers, Tim P.S. strcmp() here is a very bad idea. Other tar files may not have null bytes where you expect them (indeed, someone might deliberately craft a tar file without null bytes in order to force a crash). You should actually use memcmp() for these tests since it will check exactly the bytes you expect. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
