GNOME Bugzilla – Bug 8616
Portable path handling API
Last modified: 2011-02-18 16:13:49 UTC
Package: glib Version: cvs Looking at the source, there is no way that g_basename handles dos' (and thus win32's) two directory separators: slash and backslash. It handles only whatever G_DIR_SEPARATOR is. It has to map as follows: c:/foo/bar --> bar c:\foo\bar --> bar (Other functions, like g_path_is_absolute, need similar attention.) Morten ------- Additional Comments From tml@iki.fi 2000-04-14 23:52:48 ---- Subject: Bug#8616: g_basename does not work right on Win32 From: Tor Lillqvist <tml@iki.fi> To: 8616@bugs.gnome.org Message-Id: <14583.59280.260000.479478@gargle.gargle.HOWL> Date: Sat, 15 Apr 2000 06:52:48 +0300 (FLE Daylight Time) Morten Welinder writes: > Looking at the source, there is no way that g_basename handles > dos' (and thus win32's) two directory separators: slash and > backslash. It handles only whatever G_DIR_SEPARATOR is. > (Other functions, like g_path_is_absolute, need similar attention.) But is it useful just to fix this, while there still is tons of application code that looks in path names for G_DIR_SEPARATORs only? I think it is easier to just pretend that the only legal pathname component separator on Win32 in the backslash. (That's what end users use, anyway, isn't it?) To properly fix this mess, one would need to fully abstract the whole pathname concept, and not try to handle them with manual string scanning at all. As a bonus (?), one might then get something that would work even on "interesting" systems like VMS, where the path names are very different from either Unix or Win32. --tml ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-27 12:28 ------- This bug was previously known as bug 8616 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=8616 Originally filed under the glib product and general component. The original reporter (terra@diku.dk) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, gtkdev@gtk.org.
I think this would be properly addressed in some kind of portable file I/O layer feature for GLib, which would abstract paths, open/close/read files, etc. Not going to happen for 2.0.
Moving GLib bugs with API keyword to the API freeze milestone
Will investigate this post-2.0
What are we looking for with this bug? Something which automatically parses UNC or URI pathes too? Is this not handled by GnomeVFS? We should consider the relevancy of this bug.
*** Bug 336531 has been marked as a duplicate of this bug. ***
FWIW, we can steal a bunch of code from the Midnight Commander to do this. It has very robust functions to deal with path strings: - Compress a path with ".." and "." and multiple slashes - Canonicalize symlinks - etc.
Re: my old comment at the start, we now do have a macro G_IS_DIR_SEPARATOR which hides the fact that either / or \ are valid on Windows. And all GLib path manipulation functions now look for either separator on Windows, which they didn't do back in 2000, IIRC.
JFYI, readlink(1) has some path handling code too (canonicalizing symlinks and such).
Note that we already have at least two copies of path canonicalization functions in GTK+
Isn't this something that GIO should take care of?
Fixed with Bug 117925. Obsoleted by g_path_get_basename() and gio. Obviously a lost soul this bug.