GNOME Bugzilla – Bug 137316
Win32 behaviour of g_path_get_dirname() odd when drive letters present
Last modified: 2011-02-18 16:07:24 UTC
The current behaviour of g_path_get_dirname() with the presence of drive letters in the parameter is odd, or even incorrect. Partly this is because for a path like a:, it's hard to say what it means. It depends on what the current working directory on that drive is. It might mean a:\, or a:\some\random\place. But anyway, for some cases the current behaviour is clearly wrong. Here is the current behaviour: a:\foo\bar -> a:\foo [ OK ] a:\foo -> a: [ should definitely be a:\ ] a:\ -> a: [ should definitely be a:\ ] a:foo -> . [ wrong, a: better, even if vague ] a:foo\bar -> a:foo [ OK, input vague, output vague, too ]
Created attachment 25682 [details] [review] Suggested patch, plus additional tests to dirname-test.
Hans, do you have any opinion on this?
I think that a:foo should go to "a:." in the same way that foo goes to ".". With this change, g_path_get_dirname(<drive>:<path>) == <drive>:g_path_get_dirname(<path>) (barring double drive specifiers) which seems like a sensible rule.
most suggestions are fine with me though I always thought these c:foo stuff was a feature of the console, not the file system api. Hopefully these corner case implementation changes don't effect any of the existing use cases. Having an a:. returned looks pointless to me at least if there is no win32 api which would accept it ...
> I always thought these > c:foo stuff was a feature of the console, not the file system > api. Er, surely this has nothing to do with the console functions? Or do you mean the command interpreter, cmd.exe (or command.com)? Anyway, this is implemented also in the C library. The current directory for a drive is maintained as a system environment variable (i.e. it is not mirrorded inside the C runtime). See for instance chdir.c in the C runtime sources in the PSDK. (Or included with MSVC.) But I don't know if there is any such concept in a program that only uses the Win32 API. One would need to do some testing with GetFullPathName and relative paths and X:., and see if ever returns something else that X:\ . Perhaps some googling is called for...
> Or do you mean the command interpreter Yepp. (Should have read functionality, if there is such:) [So it is stored in the environment to be passed between different console apps ? Urgh, [remembering a bug(?) in msvcrt where only one of stat("c:\temp") and stat("c:\temp\") was a directory ]] Also I was thinking about the need to test some stange corner cases to be sure about 'expected' behaviour, but than I could not see any sane use case, at least not for me ;-)
Fix committed, behaviour as Ali suggested: 2004-03-21 Tor Lillqvist <tml@iki.fi> * glib/gutils.c (g_path_get_dirname): Fix Win32 behaviour in some cases where a drive letter is present. For 'a:' or 'a:foo', return 'a:.'. This is mostly just for consistency with the behaviour without a drive letter. But very important is to for 'a:\foo' or 'a:\', return 'a:\', and not 'a:'. (Ditto for forward slashes instead of backslashes.) (#137316) * tests/dirname-test.c (main): More complete testing on Win32. If a test fails, include expected and actual result in error message.