> Tags: wontfix
Shocking.
> This file name bug comes from conversion between wide char strings and
> multi byte strings.
Why would unrar even try to do such a thing for an archive filename on
the command line? It would make sense if this had anything to do with the
filenames stored in the archive, but that's not the case.
> These encoding conversion has so many wired pitfalls, and there is no
> trivial fix.
This is simply false: since there is no need for any conversion, the fix
is trivial, namely don't do any conversion.
Your decision to close this bugreport is wrong, please reconsider.
If you really don't know why the fix is trivial, here is how to do it:
unrar gets a filename to open as archive on the command line. This
filename is a C string in argv.
All it has to do is to use this string in e.g. the open(2) syscall. No
conversion is necessary, and any attempted conversion is simply a bug with
a trivial fix.
The proof for this is that basically every other command has no trouble
with this. If unsure, try to look at how programs such as "cat", "zip" or
"unzip" work, none of which have trouble with this.
Seriously, I have no clue how you can make such extremely wrong claims as
this being a conversion problem.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
