Re: CVS commit: src/external/bsd/libarchive/dist/libarchive

Taylor R Campbell <[email protected]>
Newsgroups gmane.os.netbsd.devel.userlevel
Message-ID <[email protected]>
> Date: Mon, 24 Aug 2026 14:55:06 +0200
> From: Thomas Klausner <[email protected]>
> 
> Personally I'm not quite sure if I want a tar tool to convert between
> encodings. Is the base encoding included in the tar file? If not, how
> does the unpacking tar know how it should interpret the byte sequence?
> It could be EUC-JP for all we know.

The archive in question is in POSIX pax interchange format, which has
_two paths_ for the file in question (written here in vis(3)
notation):

- (pax extended header `path' attribute, always UTF-8)

  meson_python-0.19.0/tests/packages/encoding/\xe3\x83\x86\xe3\x82\xb9\xe3\x83\x88.py

  Reference:
  https://pubs.opengroup.org/onlinepubs/9799919799/utilities/pax.html#tag_20_94_13_03

- (ustar record path field, exactly 100 octets, unspecified encoding)

  meson_python-0.19.0/tests/packages/encoding/???.py

  Reference:
  https://pubs.opengroup.org/onlinepubs/9799919799/utilities/pax.html#tag_20_94_13_06

POSIX prescribes of pax(1) that, for the `path' extended header
attribute:

	The pax utility shall translate the pathname of the file from
	the encoding in the header to the character set appropriate
	for the local file system.

(Our pax(1) does not understand extended headers, which is a bug we
should have fixed a long time ago but most effort has gone into
bsdtar/libarchive instead.)

This isn't authoritative for tar(1), of course.

What happened before the change I made, though, was worse than either:

(a) taking the pax extended header `path' attribute verbatim (which is
    what I would guess, but have not verified, that GNU tar does),
_or_
(b) taking the ustar path verbatim (which is what our pax(1) does).

Instead, the unpatched bsdtar would:

1. Take the pax extended header `path' attribute.

2. iconv -f UTF-8 -t 646 (i.e., convert from UTF-8 to US-ASCII, which
   is the character encoding in the C locale)

3. Use the result _despite_ iconv's report that it had to substitute
   replacement characters, in this case `?' (which happens to coincide
   with path in the ustar record, but that's just a coincidence, so to
   speak).
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.