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 688924 - gfileutils: UTF-8 breaks compatibility with g_file_test()
gfileutils: UTF-8 breaks compatibility with g_file_test()
Status: RESOLVED NOTABUG
Product: glib
Classification: Platform
Component: win32
unspecified
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-win32 maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-23 09:13 UTC by Carlo Bramini
Modified: 2017-03-29 08:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix for this bug. (1.34 KB, text/plain)
2012-11-23 09:13 UTC, Carlo Bramini
Details

Description Carlo Bramini 2012-11-23 09:13:20 UTC
Created attachment 229705 [details]
Fix for this bug.

On Windows (and only on Windows), the g_file_test() function accepts file and path names encoded in UTF-8.
Unfortunately, this solution can break the compatibility with several applications if they relies on the codepage and they are using plain ASCII strings as it normally happens, for example, in linux.
Here there is an example:

http://redmine.audacious-media-player.org/boards/1/topics/540

My proposal is the addition of a flag to inform the g_file_test() function to not proceede to the translation from UTF-8 but to use the input string as it is.
In that way, at source level the flag is safe for all other platform because it would be simply ignored (the input strings are always plain ASCII) and it won't break the compatibility with all existing if it is not specified even on Windows, since it will continue to work as it worked until now.
Attached patch shows a proposed solution to this defect.

Sincerely,

Carlo Bramini.
Comment 1 Christoph Reiter (lazka) 2017-03-29 08:50:13 UTC
If you want to use g_file_test with codepage encoded paths on Windows, you can use g_locale_to_utf8().

Looking at the code in audacious the source seems to be an URI, so just using g_filename_from_uri() should fix it, with the benefit that that supports unicode filenames (the default codepage is quite limited).