file-operations: Handle errors properly in delete_files_recursively

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().

If we weren't successful at deleting, but there's no error, that means
that a recursive call to delete failed.  In that case let's generate
our own error.

Fixes: #517

1 files changed, 8 insertions, 0 deletions

diff --git a/src/nautilus-file-operations.c b/src/nautilus-file-operations.c
index cce3b2548..59341d83e 100644
--- a/src/nautilus-file-operations.c
+++ b/src/nautilus-file-operations.c
@@ -2002,6 +2002,14 @@ delete_file_recursively (GFile          *file,
 
     if (callback)
     {
+        if (!success && error == NULL)
+        {
+            /* Enumeration succeeded, but we've failed to delete at least one child. */
+            error = g_error_new (G_IO_ERROR,
+                                 G_IO_ERROR_NOT_EMPTY,
+                                 _("Failed to delete all child files"));
+        }
+
         callback (file, error, callback_data);
     }