GNOME Bugzilla – Bug 699183
Error on unmount - This location could not be displayed
Last modified: 2014-02-04 16:35:26 UTC
After unmounting USB storage or ISO files the following error pops up: --- This location could not be displayed. “usb3” could not be found. Perhaps it has recently been deleted. --- Reproducible today using nautilus-3.8.1-1.fc19.x86_64
*** Bug 703660 has been marked as a duplicate of this bug. ***
*** Bug 703722 has been marked as a duplicate of this bug. ***
*** Bug 701994 has been marked as a duplicate of this bug. ***
As noted in bug 701994 this issue is present when using the eject button in the nautilus sidebar but not when using the shell to eject removable media.
Another salient point to reproduce is that it seems you need to have navigated to a subdirectory of the USB storage: 1) Insert USB stick 2) Navigate into the top-level with nautilus, either a) "Open with Files" or b) navigate into the USB stick within nautilus 3) Be sure to navigate to a folder deeper than the root of the drive 4) Hit eject either on the nautilus sidebar
(In reply to comment #5) > Another salient point to reproduce is that it seems you need to have navigated > to a subdirectory of the USB storage: > I'm not sure that is true (or, maybe I misunderstood) - I sometimes see this if I first click back to my home directory in nautilus, and then click the eject button from the sidebar.
(In reply to comment #6) > (In reply to comment #5) > > Another salient point to reproduce is that it seems you need to have navigated > > to a subdirectory of the USB storage: > > > > I'm not sure that is true (or, maybe I misunderstood) - I sometimes see this if > I first click back to my home directory in nautilus, and then click the eject > button from the sidebar. Quite right, I see that too. Perhaps then the issue is that you will see such errors if you click eject whilst the view is anywhere other than the root of the mounted storage being ejected?
I've finally tracked down the commit which introduced this: 277a6a45 - places-sidebar: use gtk_tree_view_set_activate_on_single_click in this commit the GtkTreeView::row-activated signal was connected to bookmarks_row_activated_cb () which in turn calls open_selected_bookmark () for the activated row. The problem is that a click on the eject icon for a volume triggers the row-activated signal and nautilus tries to open the volume which is in the process of being ejected. A simple fix is to revert 277a6a45 apart from the part which changes eel_gtk_tree_view_set_activate_on_single_click () to gtk_tree_view_set_activate_on_single_click ()
Created attachment 248944 [details] [review] Revert "places-sidebar: use gtk_tree_view_set_activate_on_single_click"
Created attachment 248945 [details] [review] places-sidebar: use gtk_tree_view_set_activate_on_single_click
The two patches attached revert to the old behaviour of making the open_selected_bookmark () call on button-release-event. As this code, and therefore this bug, now exist in Gtk+ I shall file an issue there and see if we there's a better way to resolve this.
Thanks for the investigation, but I don't really like this solution, as it also requires reverting back the eel code that was removed. Can you check for clicked_eject_button() in the callback for row-activated and avoid calling into open_selected_bookmark() if that returns TRUE instead?
(In reply to comment #12) > Thanks for the investigation, but I don't really like this solution, as it also > requires reverting back the eel code that was removed. True, if you want to ensure the tree can always be built (which one assumes you would) that would be required. > Can you check for clicked_eject_button() in the callback for row-activated and > avoid calling into open_selected_bookmark() if that returns TRUE instead? That's a much more pleasant solution! I had missed that API, thanks for the suggestion. Patch incoming.
Created attachment 248967 [details] [review] Don't call open_selected_bookmark () when the user has clicked eject
Review of attachment 248967 [details] [review]: Thanks, this is much better! Other than the comments below, looks good to be pushed to the gnome-3-8 branch. ::: src/nautilus-places-sidebar.c @@ +2931,3 @@ } + if (!clicked_eject_button (sidebar, &path)) Two little details: * Nautilus' coding style requires curly braces around every if block, even if it's only one line * You're reusing the pointer to the GtkTreePath passed in to the callback. I'd rather you had another GtkTreePath * to pass as an out arg to clicked_eject_button(). In case clicked_eject_button() returns TRUE, you should also free the returned GtkTreePath using gtk_tree_path_free().
Created attachment 248972 [details] [review] Updated patch Thanks Cosimo. Here's a cleaned up version as requested. I don't have push privileges so would appreciate you pushing to gnome-3-8 if you approve of the patch. I'll file a bug with a patch for Gtk+ master tomorrow.
Thanks a lot Joshua - I pushed the patch to gnome-3-8 now. Closing this as FIXED.
*** Bug 704892 has been marked as a duplicate of this bug. ***
Created attachment 250563 [details] umount after patch
I rebuilt nautilus using the actual git commit to the gnome-3.8 branch ( https://git.gnome.org/browse/nautilus/patch/?id=d5c09af0d7052b778e295ece5b4bdda71b779383 ) , and still notice the error upon unmount. Attached is a screenshot of a recent eject for my MP3 device. Also, the nautilus process has definitely been restarted, as I rebooted this morning for the 3.10 kernel update :-) Does one also need subsequent commits, since 3.8.2 ?
I'm still seeing this with nautilus 3.9.91.
*** Bug 709508 has been marked as a duplicate of this bug. ***
*** Bug 719866 has been marked as a duplicate of this bug. ***
*** Bug 723613 has been marked as a duplicate of this bug. ***