GNOME Bugzilla – Bug 148140
2.0 does not decode URLs dropped from DFM
Last modified: 2004-08-04 17:13:23 UTC
open("file:///data/audio/UltraPloj/%D6ver%F6sa/Omslag/Cancerpl%E4ttar.xcf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) A file in a iso-8859-1 encoded path dragged via DFM to GIMP 2.0.3. Same when dragging from Nautilus.
The file fails to open, giving these error messages: Dialogue 1: "GIMP Message: Opening 'file:///data/audio/UltraPloj/%D6ver%F6sa/Omslag/Avfallsblodpump.xcf' failed: Plug-In could not open image.". Dialogue 2: "GIMP Message: Could not open 'file:///data/audio/UltraPloj/%D6ver%F6sa/Omslag/Avfallsblodpump.xcf' for reading: No such file or directory".
When opening an ASCII file either from drag and drop or open dialogue I get: open("/home/odd/NL/Cementkulle.xcf", O_RDONLY|O_LARGEFILE) = 5
Downgrading to libglib2.0-0 (2.4.2-1) (Debian) solved this.
Sounds like a G_BROKEN_FILENAMES issue. The GIMP assumes UTF8 encoded filenames everywhere, unless G_BROKEN_FILENAMES is set. And starting from glib 2.4, that changed to G_FILENAME_ENCODING. Try running the GIMP after setting G_FILENAME_ENCODING to iso8859-1. Cheers, Dave.
I've tried that, and setting that has no effect.
This has nothing to do with G_BROKEN_FILENAMES or G_FILENAME_ENCODING. It's glib that has changed behavior immediately after the 2.4.2 release: 2004-06-07 Federico Mena Quintero <federico@ximian.com> * README.in: Added a note about the changes below. Merge from HEAD: Fixes #140532. * glib/gconvert.c (is_asciialphanum): Renamed from is_escalphanum(); ensures that this is an ASCII character. (is_asciiescalpha): Renamed from is_escalpha(). (hostname_validate): Use the two functions above. (g_filename_to_uri): Don't convert the filename to UTF-8. (g_filename_from_uri): Don't convert the filename from UTF-8. Even though it's quite strange for the functions to change behavior in the middle of a stable branch, we will have to add a runtime check here.
*** Bug 148371 has been marked as a duplicate of this bug. ***
The glib problem is handled in #148484. We keep this bug report open so that we remember to check the code after glib has been fixed.
glib-2.4.5 has been released. We should check if we need to do any changes to out URL handling before we do 2.0.4. Setting severity to blocker.
After a first glance it looks as if we just need to change the DND url decoding stuff because all other places don't care about the contents of the URI. There won't be a fix for glib == 2.4.4 however. We should pop a warning on startup which informs the user that any non-ascii filename can't be opened with that version of glib. (and no, there is no workaround :-( ...)
Not sure if this is related, but I also have a report of this happening (http://bugs.debian.org/262718): I see this message telling me to set G_FILENAME_ENCODING. So $ G_FILENAME_ENCODING=$LC_CTYPE gimp /tmp/19990716cement_big.jpg GIMP: Error parsing internal buffer: while parsing token 'web-browser': Conversion from character set 'UTF-8' to 'zh_TW.Big5' is not supported Segmentation fault
Glib 2.4.5 fixed this bug.
Fixed the remaining DND issue in both branches: 2004-08-04 Michael Natterer <mitch@gimp.org> Allow URI drops from apps linked against GLib < 2.4.4 to GIMP linked against GLib >= 2.4.5. Fixes bug #148140. * app/core/gimp-utils.[ch]: added gimp_check_glib_version(). * app/widgets/gimpselectiondata.c: added runtime check for GLib versions that encode file:// URIs correctly (>= 2.4.5). For older (broken) GLibs, leave the code path as is, for newer (fixed) ones, perform an additional check if the dropped URI is in the (broken) escaped-UTF-8 format and convert it to local filename encoding. * app/gui/gui.c: warn the user that non-ASCII filenames can't be used when linked against GLib 2.4.4.