GNOME Bugzilla – Bug 318723
confirmation dialog box for immediate deletion is only asked the first time
Last modified: 2010-07-04 23:21:38 UTC
Please describe the problem: When you delete a file or a folder which can't be moved to trash, a confirmation dialog box. If you click cancel and retry to delete the file, the confirmation dialog box doesn't popup anymore and nothing happen. Steps to reproduce: 1. Create a partition where you only have write access on a specific directory (Trash can't be created on this partition) 2. On this partition try to delete a folder or a file you have write access. 3. Click cancel button 4. Try again Actual results: The dialog box doesn't popup anymore Expected results: The dialog box should popup everytime. Does this happen every time? yes Other information: The bug happens because nautilus thinks the selection has been deleted even if I canceled the deletion. in fm-directory-view.c: static void trash_or_delete_selected_files (FMDirectoryView *view) { GList *selection; /* This might be rapidly called multiple times for the same selection * when using keybindings. So we remember if the current selection * was already removed (but the view doesn't know about it yet). */ if (!view->details->selection_was_removed) { selection = fm_directory_view_get_selection_for_file_transfer (view); trash_or_delete_files (view, selection); nautilus_file_list_free (selection); view->details->selection_was_removed = TRUE; } } view->details->selection_was_removed is set to TRUE even if trash_or_delete_files didn't succeed because of the cancelation.
Thanks for your bug report and for tracking down this issue!
Created attachment 53410 [details] [review] Proposed patch Also available (with short explanation) under: http://mail.gnome.org/archives/nautilus-list/2005-October/msg00090.html
Comment on attachment 53410 [details] [review] Proposed patch Alex comment from the list: That is a very strange place to add that. It doesn't help the delete case, only move to trash, and even then it catches all moves that result in no emission of add_file before the gnome-vfs callback is called, which i expect is most moves. Unfortunately there is really no good place to hook into failure of the delete operation. Maybe we should just do it in a timeout?
Apologies for spam... marking as AP4 to reflect accessibility impact.
Is this still a problem in a recent version of nautilus as we've migrated to gvfs a long time ago?
Just tried and it seems to work fine.