Re: tar vs device special files

[RVP <rvp%SDF.ORG@localhost>]

On Sat, 28 Oct 2023, Mouse wrote:

> I'm having trouble seeing what's responsible, and in particular am
> wondering whether this is my bug or /bin/tar's bug or what.  (It
> doesn't help that I haven't managed to find a clear spec for tar
> format; the closest I've found so far is a description of what pax, in
> its (supposedly-)tar-compatible mode, is supposed to read/write.)

All of this can be found in:

src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c

If the libarchive tar doesn't see a "ustar  \0" (GNU tar) or "ustar"
(POSIX tar) magic at 0x101 (see: tar_read_header()), it take the
file to be a non-POSIX old-style tar archive which (according to
libarchive) doesn't store maj./min. nos. (see: struct archive_entry_header_ustar)

> The 9.1 /bin/tar tarball (hexdump -C) is
>
> 000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000100  00 75 73 74 61 72 00 30  30 72 6f 6f 74 00 00 00  |.ustar.00root...|
> 00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000120  00 00 00 00 00 00 00 00  00 6f 70 65 72 61 74 6f  |.........operato|
> 00000130  72 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |r...............|
> 00000140  00 00 00 00 00 00 00 00  00 30 30 30 30 30 33 20  |.........000003 |
> 00000150  00 30 30 30 30 30 33 20  00 00 00 00 00 00 00 00  |.000003 ........|
> 00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>
> whereas mine is
>
> 000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000140  00 00 00 00 00 00 00 00  00 30 30 30 30 30 33 20  |.........000003 |
> 00000150  00 30 30 30 30 30 33 20  00 00 00 00 00 00 00 00  |.000003 ........|
> 00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

> Except for the stuff at offsets 0x100-0x131, they look pretty close to
> identical to me (the value at 0x94 is the header checksum), and that
> stuff is, as far as I can tell, owner name strings (which I'm not
> supplying, just using the numeric uid and gid values).  But the stock
> 9.1 tar seems to be taking the 000003 major and minor numbers as zero
> for reasons I don't understand, since it understands its own,
> apparently identical, major and minor numbers just fine.
>
> Any ideas?

Maybe your tar could supply a "ustar" magic char. seq. at 0x101 for libarchive.
(see: header_ustar() vs. header_old_tar())

Or, fix libarchive like this:

```
diff -urN a/src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c b/src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c
--- a/src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c	2019-07-24 13:50:23.000000000 +0000
+++ b/src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c	2023-10-28 22:10:28.778721000 +0000
@@ -1383,6 +1383,14 @@
 	if (err > err2)
 		err = err2;

+	/* Parse out device numbers only for char and block specials. */
+	if (header->typeflag[0] == '3' || header->typeflag[0] == '4') {
+		archive_entry_set_rdevmajor(entry, (dev_t)
+		    tar_atol(header->rdevmajor, sizeof(header->rdevmajor)));
+		archive_entry_set_rdevminor(entry, (dev_t)
+		    tar_atol(header->rdevminor, sizeof(header->rdevminor)));
+	}
+
 	tar->entry_padding = 0x1ff & (-tar->entry_bytes_remaining);
 	return (err);
 }
```

-RVP