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