GNOME Bugzilla – Bug 567605
On Win32 port the drive letter is not shown (regression)
Last modified: 2018-05-24 11:41:04 UTC
Please describe the problem: In the 2.14 release the drive letter is no longer shown in the File Chooser's first location button. Instead of "c:\" it just shows "\" This is a regression as it worked correctly in 2.13 Steps to reproduce: 1. (On Ms Windows using GTK binaries)Invoke a file chooser dialog (e.g from gtk.demo.exe). 2. Look at the first location button (the one after . Actual results: It just shows "\" Expected results: It should show the selected drive letter as well e.g. "c:\" Does this happen every time? Yes Other information:
Confirming on Vista, with gedit 2.28.0, browsing to C: and D: It might be worth fixing this for UNC paths too - I've put more info on how that might work here: https://bugzilla.gnome.org/show_bug.cgi?id=568429#c3
Somewhere between GTK+-2.12.11 and GTK+-2.14.7 [1], the filechooser code was ported to use GIO's g_file_* functions instead of gtk_file_*. Tracing what happens today with GTK+ 2.24.5 and GLib 2.28.8, this is the order in which various functions are called: * gtk/gtkpathbar.c::gtk_path_bar_get_info_callback() V calls * gio/gfileinfo.c::g_file_info_get_display_name() V asks * gio/gfileinfo.c:: g_file_info_find_value() to fetch G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME > The value returned here is / Cool, but where and how is that attribute set exactly? Here goes: * gio/glocalfileinfo.c::_g_local_file_info_get() V gets called with path=C:\ and eventually calls * glib/gconvert.c::g_filename_display_basename() V gets called with file_name=C:\ and eventually calls * glib/gutils.c::g_path_get_basename() > which decides that a "string only containing slashes and a drive" is equivalent to G_DIR_SEPARATOR_S and returns / Bummer, this is documented behavior for g_path_get_basename [2]. But what's really surprising (at least to me) is the difference in behavior between GLib's g_path_get_basename and GIO's g_file_get_basename? Like we see above, GLib's g_path_get_basename eats the "drive letter" and returns a / but according to [3] GIO's g_file_get_basename will return a single directory separator (and on Windows, possibly a drive letter). Let's experiment a little: g_path_get_basename for 'C:' = \ g_file_get_basename for 'C:' = C: g_path_get_basename for 'C:\' = \ g_file_get_basename for 'C:\' = \ g_path_get_basename for 'C:/' = \ g_file_get_basename for 'C:/' = \ Well, even g_file_get_basename would get it wrong for the pathbar so it's a bit unclear how to proceed... [1] As far as I can see: http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.13/gtk+-2.13.3.news [2] http://developer.gnome.org/glib/2.28/glib-Miscellaneous-Utility-Functions.html#g-path-get-basename [3] http://developer.gnome.org/gio/2.28/GFile.html#g-file-get-basename
*** Bug 538365 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/185.