Skip to content

file-operations: Handle errors properly in delete_files_recursively

Corey Berla requested to merge wip/corey/recursive-delete into main

The callback function in delete_files_recursively() uses the results from its GError to determine if it should call nautilus_file_changes_queue_file_removed() (which ultimately calls the list-base remove_file() function).

This normally, works as expected, except when one of the child files fails to delete. We check for recursive deletion failures, but we never get the error that caused that failure. This means that the callback function will believe that the parent folder was deleted (when it really wasn't), and the item will disappear from the view in Nautilus because of the call to nautilus_file_changes_queue_file_removed().

Let's keep the same logic, but pass copies of the GError upon any failures. Our existing logic already handles the (expected) error DIRECTORY_NOT_EMPTY.

Fixes: #517 (closed)

Merge request reports