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 159664 - g_get_home_dir (and g_get_tmp_dir) no longer works with "non-7-bit" home dir on win32
g_get_home_dir (and g_get_tmp_dir) no longer works with "non-7-bit" home dir ...
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: win32
2.5.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-win32 maintainers
Depends on:
Blocks:
 
 
Reported: 2004-11-27 23:03 UTC by Robert Ögren
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simple test program (550 bytes, text/plain)
2004-11-27 23:05 UTC, Robert Ögren
  Details
Suggested patch (8.41 KB, patch)
2004-11-28 15:34 UTC, Tor Lillqvist
needs-work Details | Review
Dosc patch (1.68 KB, patch)
2004-11-28 15:36 UTC, Tor Lillqvist
none Details | Review

Description Robert Ögren 2004-11-27 23:03:25 UTC
Using glib from CVS HEAD, g_get_home_dir no longer works when my home directory
contains non-7-bit characters such as "Ö" and its location is fetched from
environment variables. The filename encoding patch from bug 101792 seems to have
broken this. I think the problem is that g_get_any_init in glib/gutils.c doesn't
convert the values from the environment variables (for example HOME or
USERPROFILE) to UTF-8 before storing in g_home_dir. 

The home dir is "C:\Documents and Settings\Robert Ögren" and I'm running on
Windows XP.

I have tested this with a simple program that calls g_get_home_dir. If the
program is compiled against glib-2-4, g_get_home_dir returns the correct dir
when the program is run with the glib-2-4 binaries in the path, and returns NULL
when the program is run with the HEAD binaries in the path. When the program is
compiled and run against HEAD glib binaries, g_get_home_dir returns a directory
but g_filename_to_utf8 then fails on it.

I have tested both using cmd.exe (where USERPROFILE is the only thing set), and
Cygwin bash (where HOME is set also).

The same problem seems to affect g_get_tmp_dir as well (actually for me TEMP and
TMP are usually set to the lovely short name version,
C:\DOCUME~1\ROBERT~1\LOKALA~1\Temp ...).
Comment 1 Robert Ögren 2004-11-27 23:05:33 UTC
Created attachment 34200 [details]
Simple test program

Here's the test program I used.
Comment 2 Tor Lillqvist 2004-11-28 13:51:17 UTC
The bug #101792 changes to gutils.c were buggy; will fix. Will also change 
g_get_user_name() and g_get_real_name to return UTF-8, and add binary 
compatibility versions for them, too, that will continue to return system 
codepage strings.
Comment 3 Tor Lillqvist 2004-11-28 15:34:54 UTC
Created attachment 34228 [details] [review]
Suggested patch

Please test.
Comment 4 Tor Lillqvist 2004-11-28 15:36:43 UTC
Created attachment 34229 [details] [review]
Dosc patch
Comment 5 Robert Ögren 2004-11-28 17:26:17 UTC
Comment on attachment 34228 [details] [review]
Suggested patch

It looks good except for one serious bug - if HOME is not set, then home_utf8
is used even though it is uninitialized. After I changed that, it works fine
without HOME as well. 

(If one runs in a Cygwin bash shell, the USERPROFILE environment variable is in
some other encoding and must be unset if HOME is not set. I guess Cygwin
converts it. If I run from cmd.exe, USERPROFILE is correct. So it should work
fine in all normal cases :)

I also had to remove g_file_tree_walk from glib.symbols to make it compile, I
can't find that function anywhere in the sources?
Comment 6 Tor Lillqvist 2004-11-28 18:39:48 UTC
Oops, thanks. 

The g_file_tree_walk was a leftover from testing a suggested API addition.

Fix committed.