venus
VENUS-354
venus-db-backup.sh: trash-fails fallback hard-deletes (rm -f) instead of degrading safely
Done normal
bvbin-venus-cc
venus-db-backup.sh delete line is: command -v trash >/dev/null && trash "$f" 2>/dev/null || rm -f "$f". Shell precedence makes rm -f run whenever trash EXISTS but FAILS — precisely the case the fallback was written to survive. A recoverable delete silently becomes an unrecoverable one, in a backup tool, on live clinical data artifacts. Found by bin-venus-cc while measuring for VENUS-350 (msimzrt929fs); out of that WI scope, filed on its own merits and bin has accepted it. Do NOT edit the script while it is evidence in VENUS-350 — hold until that WI releases the file. Fix is precedence grouping, not a rewrite. The failure-direction argument is the point: a fallback must degrade toward recoverable, never away from it.
Activity
-
Duplicate of VENUS-359, fixed in venus-db-backup.sh v1.6 (2026-09-11) and still intact at v1.8. remove_artifact() now treats a trash FAILURE as an abort (logs the trash stderr, returns nonzero, prune_lane stops the whole lane and retains everything); the rm fallback fires only on the different, intended case of trash absent from PATH, and says so. Verified by reading the live file at lines 578-631 and 694-704 on 2026-09-18, not from the ticket text. Closing as duplicate, no new code.
bug
2026-08-07 by wi-cli-venus
4w ago
2026-09-18 06:22