Re: tar vs device special files

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> (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

Thank you!  I'll have a look.

> 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)

That is ... a significant deviation from historical practice, to the
extent that I would call it a bug in libarchive's tar support.  (I
don't think I've ever stumbled across any other tar that didn't
understand mtar's archives, though admittedly I don't pass archives
including device special files between implementations very often, so
if the incompatibility is limited to them I might well not notice.)

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

I'll read the file you pointed at (though the path makes it sound like
a description of what libarchive chooses to do rather than anything
authoritative, though admittedly I don't know whether there _is_
anything authoritative when it comes to tar in general, as opposed to
specific tar implementations).

> Or, fix libarchive like this: [...]

If this isn't just a NetBSD oddity, I'd prefer to generate archives
that are more widely compatible.  Maybe even if it is.  Either way,
fixing libarchive is counterindicated (unless NetBSD is willing to take
up the changes, which strikes me as unlikely).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B