fix: enhance nested subvolume deletion verification process #467
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Background
When deleting an old snapshot in BTRFS mode, the current version of Timeshift deletes certain subdirectories as subvolumes recursively (here):
In this way, Timeshift correctly handles situations like
timeshift-btrfs/snapshots/xxx/@/@. However, btrfs-progs cannot delete an ordinary directory like a subvolume:The Problem
Similarly, if a
/@directory gets a snapshot, then Timeshift would treat it as a subvolume when deleting the snapshot. Steps to reproduce:I suspect there have been similar problems around for a while:
The Fix
My proposal first checks if there's indeed a subvolume before running
btrfs subvolume delete.btrfs subvolume showoutputs nothing to the stdout if there's not a subvolume. After applying the fix, the previously failing deletion succeeded:Environment: