v0.3.5: log the recursive-delete failure instead of swallowing it

delete_snapshot_tree tries one recursive delete first, then falls back to sweeping
the tree by name. The exception from the fast path was discarded.

That failure is usually benign -- stock's finally already removed the parent once
our mounts were released, which is exactly what the sweep exists to handle. But if
the cause were anything else, this was the only place it was ever visible, and it
went straight to /dev/null. The sweep would then report some different, downstream
symptom. It is now logged before falling through.

Also annotated the two remaining static-analysis findings as considered rather than
leaving them to be re-litigated every audit: subprocess is always invoked in list
form (no shell, so ZFS dataset names cannot inject), and a partial `systemctl` path
is moot in a script that only ever runs as root.

Extended ruleset (E,F,W,B,S,SIM,UP,C4,RET,ARG,A,ISC) and shellcheck -S style both
report zero. 132 tests.

This commit is contained in:

flan

2026-07-13 16:06:12 +00:00

parent 126756498c

commit 45f957af23

7 changed files with 39 additions and 9 deletions

									
										uninstall.sh
									
		+1
		-1
	
												View File
												
				@@ -3,7 +3,7 @@

				set -euo pipefail

				VERSION="0.3.4"

				VERSION="0.3.5"

				PATCH_DIR="$(cd "$(dirname "$0")" && pwd)"

				_HOOK_COMMENT='TrueCloud provider patch (S3/B2)'