GNOME Bugzilla – Bug 316301
Can't move files to trash from search results
Last modified: 2008-09-10 06:55:55 UTC
Please describe the problem: Can't move files to trash from search results, says it all. Search for something and select "move to trash" from the contextual menu it reports "Trash is unavailable" even if moving files to trash from a normal nautilus window works. It then goes on to suggest to delete the file instead, this functionality is not broken but very inconvinient for the user. It pops up a dialog for every selected file and there is no way to cancel all deletions at once, you have to choose cancel for every file. Steps to reproduce: 1. Search for files 2. Enter query 3. Right click, select move to trash Actual results: Described above. Expected results: The user should be able to move files to the trash. Does this happen every time? Yes Other information: Yes, if you select multiple files there comes a dialog for each and every file, where you have to either confirm a "real deletion" or cancel the operation. Very annoying when I happend to select many files...
Now this behavior has changed, not for the better. You can't move search results to the trash NOR can you delete them. Which means I need to go back to my trusty old file-manager, /usr/bin/bash. To reproduce. 1.Search 2a.Select a resulting file and press Delete. (2b.Right-click on a file and notice that Move to Wastebasket is grayed out.) Actual results: Nothing happens Expected results: The file is moved to trash This happens with Nautilus 2.14.3.
I stand corrected. This bug actually contains two bugs: 1)Search results aren't updated when a file is erased using the keyboard. The number of files remains the same, despite an apparent redraw by Nautilus. This gives the impression there was no effect. 2)The move to Wastebasket is grayed out, despite the fact that you can move to Trash (Delete on the keyboard does move it to the Trash). Should these two bugs be seperated?
Still reproducable. Confirming.
Created attachment 78749 [details] [review] Proposed patch This patch was also sent to nautilus-list for review.
are there any news regarding the inclusion of the patch? i'm running version 2.17.90 and this behaviour is still there and annoying.
Comment on attachment 78749 [details] [review] Proposed patch Alex commented on nautilus-list: On Mon, 2007-01-01 at 21:52 +0100, Christian Neumair wrote: > Am Donnerstag, den 21.12.2006, 20:49 +0100 schrieb Christian Neumair: > > Nautilus used to query whether the displayed location is readable when > > deciding whether files are readable. It should rather consider the > > selected files themselves. > > > > Proposed patch attached, should fix bug 316301: > > http://bugzilla.gnome.org/show_bug.cgi?id=316301 > > Hrm this is obviously wrong for UNIX-like permissions. > > Calling nautilus_file_can_rename() for each selected item might be > better, but I'm not sure whether this applies for all file systems. The problem is that we're calling can_write on the directory that we're displaying (i.e. a virtual search location), but what is really needed is to look at the directory of each selected file and see if that is writable. Of course, the is_writable check is only totally right for somewhat posix-like semantics, and this calls for separate can_move() calls in gvfs.
*** Bug 336028 has been marked as a duplicate of this bug. ***
any chance this is already fixed in latest gnome/nautilus?
sorry. my fault. it is NOT fixed. the option is there but files are not moved to the trash but deleted directly.
the issue seem to be fixed in the current version
It's fixed. Somebody with permissions should close it.
Closing as for last comments.