]> git.ipfire.org Git - thirdparty/libarchive.git/commit
Update 'archive_mstring_update_utf8' to attempt UTF8->WCS conversion on Windows if...
authorDuncan Horn <40036384+dunhor@users.noreply.github.com>
Mon, 18 Mar 2024 02:49:56 +0000 (19:49 -0700)
committerGitHub <noreply@github.com>
Mon, 18 Mar 2024 02:49:56 +0000 (19:49 -0700)
commitaafb078b7cfaed3af4edbf9cb31d3ed930323aca
tree219cbe2d6d6e5c98289add43b9f7e685a97d36c0
parent9b77c049e1306b9b0b0d3ed683926fc4ec8cd078
Update 'archive_mstring_update_utf8' to attempt UTF8->WCS conversion on Windows if MBS conversion fails (#1978)

Currently, functions like `archive_entry_pathname_w` etc. fail on
Windows for .rar files that contain entries with Unicode filenames that
cannot be represented by the active codepage. This is because
`archive_mstring_update_utf8` first attempts to perform a UTF8->MBS
conversion before doing an MBS->WCS conversion. The first conversion (to
MBS) fails, which short-circuits to return failure. Later when we try
and read the string, `archive_mstring_get_wcs` will fail because it
_also_ tries to do a UTF8->MBS followed by an MBS->WCS conversion. The
conversion to MBS will of course fail again.

One possible workaround is to call `setlocale` with something like
`"en_US.utf8"`, however this is not feasible for some consumers.

This change fixes this issue by adding a "fallback" in
'archive_mstring_update_utf8' which will attempt to do a UTF8->WCS
conversion on Windows if the MBS conversion failed. This is not too
dissimilar from the implementation of `archive_mstring_copy_mbs_len_l`
which most - if not all - other archive formats seem to take, which will
by default call `archive_wstring_append_from_mbs_in_codepage` if the
passed in `archive_string_conv` object is non-null

Fixes #1971
libarchive/archive_string.c
libarchive/test/test_read_format_rar5.c
libarchive/test/test_read_format_rar5_unicode.rar.uu [new file with mode: 0644]