Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • Files Files
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 423
    • Issues 423
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 71
    • Merge requests 71
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • FilesFiles
  • Merge requests
  • !1102

file-operations: Handle errors properly in delete_files_recursively

  • Review changes

  • Download
  • Email patches
  • Plain diff
Open Corey Berla requested to merge wip/corey/recursive-delete into master Jan 16, 2023
  • Overview 5
  • Commits 1
  • Pipelines 2
  • Changes 1

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

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: wip/corey/recursive-delete