After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 361321 - [Win32] Fails to open file from command line with a Chinese path
[Win32] Fails to open file from command line with a Chinese path
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
1.7.x
Other Windows
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 426678 440991 (view as bug list)
Depends on: 522131
Blocks:
 
 
Reported: 2006-10-11 02:34 UTC by Shixin Zeng
Modified: 2008-03-13 02:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Shixin Zeng 2006-10-11 02:34: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.
Comment 1 Morten Welinder 2006-10-11 14:49:58 UTC
Likely an encoding problem.  Ivan?
Comment 2 Jon Kåre Hellan 2006-10-18 21:58:39 UTC
I have the same bug when trying to open a file in folder 'Bærtur' by double clicking it.
Comment 3 Kriz 2007-07-29 12:05:44 UTC
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. 
Comment 4 Shixin Zeng 2007-10-29 20:41:12 UTC
It was not fixed for 1.7.12, although the announcement of that release mentioned this bug.
Comment 5 Jody Goldberg 2008-03-02 15:17:32 UTC
replicated with 1.9.0
Comment 6 Jody Goldberg 2008-03-04 00:25:50 UTC
*** Bug 426678 has been marked as a duplicate of this bug. ***
Comment 7 Jody Goldberg 2008-03-04 00:26:17 UTC
*** Bug 440991 has been marked as a duplicate of this bug. ***
Comment 8 Jody Goldberg 2008-03-12 23:59:34 UTC
Patched in the latest win32 build.
1.9.0-20080312
Comment 9 Shixin Zeng 2008-03-13 01:03:14 UTC
it works fine with this build: 1.9.0-20080312
Thanks.
Comment 10 Morten Welinder 2008-03-13 01:09:27 UTC
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.
Comment 11 Shixin Zeng 2008-03-13 01:20:59 UTC
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?
Comment 12 Morten Welinder 2008-03-13 02:12:34 UTC
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.
Comment 13 Shixin Zeng 2008-03-13 02:16:03 UTC
That makes sense. Thanks!