Same thing on my system. Right click >> "Open containing folder" opens the file in the default app.

Lubuntu 12.04 "Precise Pangolin"

gnome-search-tool_3.4.0-1_i386.deb

I get the same behavior with gnome-search-tool 3.4.0-2 on Debian Testing. I searched for a file (in this case a word document, .doc. If I right click on the file and click "Open Containing Folder" it instead opens the file in LibreOffice. I get the same behavior (opening with the default application) with text files and all others I have tried.

Linux 3.2.0-2-amd64 #1 SMP x86_64 GNU/Linux

I should also mention that this happens while running under Gnome, not XFCE.

I'm fairly certain this is happening because of the bit of code below

/* from gsearchtool-callbacks.c:open_folder_cb */

		if (open_file_with_application (gsearch->window, locale_folder, g_app_info) == FALSE) {

			if (open_file_with_filemanager (gsearch->window, locale_file, TRUE) == FALSE) {

				display_dialog_could_not_open_folder (gsearch->window, utf8_folder);

				g_list_foreach (list, (GFunc) gtk_tree_path_free, NULL);
				g_list_free (list);
				g_free (locale_folder);
				g_free (utf8_folder);
				g_object_unref (g_file);
				g_object_unref (g_file_info);
				g_object_unref (g_app_info);
				return;
			}
		}

It looks like it attempts to open the file with an application before ever attempting to open with the filemanager. If it succeeds in opening with the application then it does not run the code to open with filemanager. It looks like removing the outer if statement would resolve this, but I need to set up a development environment for this project to confirm.

Created attachment 216361 [details] [review]
Patch to fix behavior of "Open Containing Folder" when default handler is exo-open

My first instinct was wrong. Although I am running Gnome, my default file manager as detected by gsearchtools-support.c:open_file_with_filemanager is apparently exo-open. I think this is because I also have XFCE installed and Thunar is my default file manager.

I'll try to be as explicit as I can:

In gsearchtools-support.c:open_file_with_filemanager the command variable gets set to "exo-open ".

The list variable is a GList of uris that will eventually be called as an argument to the detected default handler (in our case, exo-open). This list gets populated with URIs for all the selected files. The problem is that if exo-open receives argument that are files it will then open those files with their default handler, and does not open the file manager at all.

I have attached a patch that detects if we got "exo-open " as the command and removes the filename from the end of each URI before appending it to the list. This is the same behavior as when the file was found to be a directory in the first place, so I have combined it with that code.

There may be a cleaner way to do this. Ideally we would want to have the same behavior in Thunar as in Nautilus (the directory opens with the file selected), but I am not sure how to accomplish that through exo-open, and Thunar apparently does not have the same behavior as Nautilus when supplied with a file argument. It defaults to opening the file with the associated program. This at least fixes things for people who use exo-open.

(In reply to comment #1)
> Same thing on my system. Right click >> "Open containing folder" opens the file
> in the default app.
> 
> Lubuntu 12.04 "Precise Pangolin"
> 
> gnome-search-tool_3.4.0-1_i386.deb

I notice that this is still labeled as "Unconfirmed" and just wanted to add that this affects me as well and has so for as long as I can remember. Hopefully if this patch does work, (Haven't tried it yet) it will get added to the core at some point.

OS: Ubuntu 12.04 x86_64
Kernel: 3.2.0-68-generic
Window Manager: Xfwm 4.10.1 (revision 3918e6b)
Desktop Environment: Xfce 4.10
File Manager: Thunar 1.6.3

gboolean
open_file_with_filemanager (GtkWidget * window,
                            const gchar * file,
                            gboolean open_parent)
{
	GDesktopAppInfo * d_app_info;
	GKeyFile * key_file;
	GdkAppLaunchContext * ctx = NULL;
	GList * list = NULL;
	GAppInfo * g_app_info;
	GFile * g_file;
	gchar * command;
	gchar * contents;
	gchar * uri;
	gboolean result = TRUE;

	if (open_parent == TRUE && g_file_test (file, G_FILE_TEST_IS_DIR)) {
		gchar * folder = g_path_get_dirname (file);
		uri = g_filename_to_uri (folder, NULL, NULL);
		g_free (folder);
	}
	else {
		uri = g_filename_to_uri (file, NULL, NULL);
	}
...

The problem is at:
   if (open_parent == TRUE && g_file_test (file, G_FILE_TEST_IS_DIR)) {
should be:
   if (open_parent == TRUE && g_file_test (file, G_FILE_TEST_IS_REGULAR)) {

gnome-search-tool is not under active development anymore.
Its codebase has been archived:
https://gitlab.gnome.org/Archive/gnome-search-tool/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather reactivate the project
to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the
responsibility for active development again.