After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 318723 - confirmation dialog box for immediate deletion is only asked the first time
confirmation dialog box for immediate deletion is only asked the first time
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: Views: All
2.13.x
Other All
: Normal minor
: 2.14.x
Assigned To: Nautilus Maintainers
Nautilus Maintainers
AP4
Depends on:
Blocks:
 
 
Reported: 2005-10-13 00:09 UTC by Yann Rouillard
Modified: 2010-07-04 23:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Proposed patch (860 bytes, patch)
2005-10-13 11:10 UTC, Christian Neumair
needs-work Details | Review

Description Yann Rouillard 2005-10-13 00:09:42 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.
Comment 1 Christian Neumair 2005-10-13 11:05:57 UTC
Thanks for your bug report and for tracking down this issue!
Comment 2 Christian Neumair 2005-10-13 11:10:32 UTC
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 3 Martin Wehner 2005-12-16 21:52:12 UTC
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?
Comment 4 Calum Benson 2006-04-26 17:47:56 UTC
Apologies for spam... marking as AP4 to reflect accessibility impact.
Comment 5 Marcus Carlson 2010-07-04 21:13:45 UTC
Is this still a problem in a recent version of nautilus as we've migrated to gvfs a long time ago?
Comment 6 Cosimo Cecchi 2010-07-04 23:21:38 UTC
Just tried and it seems to work fine.