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

>> On a Debian system (where bsdtar is presumably using GNU iconv), if
>> I try this, it fails in exactly the same way with LANG=C and works
>> with LANG=C.UTF-8.

!

>> archivers/bsdtar is built without any iconv at
>> all, so it rejects the archive altogether no matter what your locale
>> is!

!!  So, it either (a) refuses to tar up certain pathnames or (b)
refuses to extract the resulting archive or (c) generates an archive
containing names different from the original names?  I'd call any of
those catastrophically broken.  Extremely non-Unixy.

>> And as far as I know, there's no way to ask bsdtar/libarchive to
>> just treat each path as a sequence of bytes without interpretation.

I find it astonishing that _any_ tar implementation would treat
pathnames as anything but opaque octet strings.  If I ran into this I'd
be filing "renders it unusable" bug reports for the implementation in
question (well, if I could find a usable bug-reporting address for it).

> Personally I'm not quite sure if I want a tar tool to convert between
> encodings.

I'm quite sure I don't.  If I ever personally run into a tar that
treats pathnames as anything but opaque (except for slash and NUL)
octet strings, I will consider it outright broken.

Makes me glad I have my own tar implementation.

Actually, it reminds me of the sqlite people.  I asked them about using
non-UTF-8 filenames for databases (the doc says that using non-UTF-8
filenames provokes undefined behaviour) and the response - and this is
a direct quote - was "What's the problem?  Are you wanting to name a
database with some octet sequence that is not valid UTF-8?  Why would
you want to do that?".  Absolutely jaw-dropping.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B