GNOME Bugzilla – Bug 361321
[Win32] Fails to open file from command line with a Chinese path
Last modified: 2008-03-13 02:16:03 UTC
Please describe the problem: If a file located in a Chinese directory, double click it will fail to open it with the error: "... Not such file or directory" My system is Windows XP SP2, Simplified Chinese version. And my Gnumeric is 1.7.1 downloaded from http://www.gnome.org/~mortenw/gnumeric/gnumeric-1.7.1-win32-1.exe Steps to reproduce: 1. save a gnumeric file in a Chinese directory. e.g C:\中文\test.gnumerc 2. Open the directory with Explorer 3. double click on the file Actual results: fail to open it with the error: "... Not such file or directory" Expected results: Open it Does this happen every time? yes Other information: Perphaps this is caused by the difference between local path encoding and UTF-8. As in the error message dialog, the file path is garbaged text.
Likely an encoding problem. Ivan?
I have the same bug when trying to open a file in folder 'Bærtur' by double clicking it.
I'm able to reproduce the problem with cyrilic file names. ´ My system/configuration: OS: Windows XP Professional SP2 English US/MUI version System locale: en_us (=Language for non-Unicode programs) User locale: de_at User UI languge: en_us The problem lies in main-application.c The main entry point of Gnumeric is defined as int main (int argc, char **argv) which will always be called with "Ansi" strings (i.e. SBCS/DBCS code page based strings) by the c runtime library. During the conversation process from UTF-16 to "Ansi" all characters outside the system locale (=Language for non-Unicode programs) code page will be replaced by ? I'm not sure whether Gnumeric is a Unicode application but looks like it is using mainly UTF-8 strings. A possible fix is rather easy provided Gnumeric is indeed a Unicode application using UTF-8 stings (it does not look like it is using UTF-16). Somewhere at the beginning of main() GetCommandLineW() needs to be called to retrieve the Unicode (UTF-16) version of the command line string. Next this string has to be converted from UTF-16 to UTF-8 and parsed and split to produce argc and argv in UTF-8.
It was not fixed for 1.7.12, although the announcement of that release mentioned this bug.
replicated with 1.9.0
*** Bug 426678 has been marked as a duplicate of this bug. ***
*** Bug 440991 has been marked as a duplicate of this bug. ***
Patched in the latest win32 build. 1.9.0-20080312
it works fine with this build: 1.9.0-20080312 Thanks.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Yes, I wanted to mark it as fixed, but I just don't understand the dependence on the bug 522131. To my best understanding, a bug can't be fixed if its dependency bug is not fixed, right?
The patch mentioned in bug 522131 is in the new build you have. We just would like it, or something like it, to enter the official glib build.
That makes sense. Thanks!