GNOME Bugzilla – Bug 688924
gfileutils: UTF-8 breaks compatibility with g_file_test()
Last modified: 2017-03-29 08:50:13 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.
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).