GNOME Bugzilla – Bug 781302
Cannot open directories with associated application (i.e. Windows Explorer)
Last modified: 2018-05-24 19:29:18 UTC
Created attachment 349853 [details] Make opening directories work The attached patch fixes several related issues that are preventing directories from being opened (via e.g. gtk_show_uri()) on Windows. Issue #1: A content-type of "inode/directory" is explicitly assigned to directories as a special case (most other content types are file extensions), but this case is not handled in the registry lookup code. The registry doesn't have a key for "inode/directory" but it does have one for "Folder" (also "File Folder", not sure which one we should use). Issue #2: In some cases (including the "Folder" case) g_win32_app_info_supports_uris() and g_win32_app_info_supports_files() can both return FALSE. In this case we should assume that the application does not support URIs and give it local file paths if possible. Issue #3: The code is currently translating all backslashes in the command-line to forward slashes. This breaks e.g. Windows Explorer, which will open "C:\Windows" but will not open "C:/Windows". Forward slashes are traditionally used for option switches since the DOS days, so we should not be using them for path delimiters.
ShellExecute() works with "C:/Windows", so this must be purely the problem of explorer.exe commandline argument handling. Also, i would *like* for glib to use mime/types more, which means more of the "inode/directory" types being around. So this boils down to: 1) Do we want to handle generic "open/show file" for folders by delegating the task to Windows via ShellExecute() or similar APIs (most likely COM), OR keep using the information we get from the registry (which is "%SystemRoot%\Explorer.exe" by default) by transforming "inode/directory" into "Folder"? The former is more straightforward, and has no slash/backslash problem. The latter is more correct (since the registry might contain non-standard handlers for the "Folder" type). Although that depends on the APIs used for the former case - some of them might very well just roughly the same thing (look up the registry, and do what it says, except that MS functions can probably do it better than we do). 2) If the former, then where should that (delegation) be handled? If the latter, then how do we deal with backslashes - there's no telling how much processing could happen to a path, and glib does tend to normalize paths by converting backslashes to slashes. Converting forward-slashes *back* to backslashes doesn't seem to be an option. Or maybe it is, if we keep a special case for "Folder" or "inode/directory". An aside: running "explorer.exe file://c:/windows" does work. In fact, even "file:c:/windows" works.
Good thoughts. If ShellExecute() is a more elegant approach than that's fine with me. I don't really have an opinion on how it works, as long as it works. :) It's interesting that explorer.exe does handle the URIs; I'm not sure why I thought otherwise.
-- 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/1259.