mirror of
https://github.com/euzu/tuliprox.git
synced 2026-10-22 07:42:22 +02:00
DarkBreakpoint
dcfbf82c49
Sweep of the paths that still assumed one entry owns one file. Deletion was fixed when the assumption broke; these two were not, and both are silent. Disk pressure credited itself the full file size whenever the delete callback returned `Ok`. Since a shared-file deletion correctly unlinks nothing, a pass could "reclaim" gigabytes that never left the disk, satisfy its low-watermark check on those phantom bytes, stop early, and report success with the disk still full -- `pressure_unrelieved` would read false. `system_retention_delete` now reports whether the file was actually unlinked and `DeleteOutcome::Detached` carries that: the entry counts as deleted, its bytes do not count as reclaimed, and the pass keeps looking for something that genuinely frees space. Startup reconciliation inferred "file still present, so the unlink never ran, so restore the recording". That inference was sound when a file had one owner. Now a correct deletion deliberately leaves a shared file alone, so a crash between the unlink step and the finalize step would resurrect a recording the user had deleted -- and it would come back on every boot until someone else's entry went away. `recovery_action_for` takes `still_referenced` and finishes the deletion instead. Both use the same holder rule as the deletion path, including excluding entries that are themselves mid-deletion, so a crash between two deletions cannot strand the file either. Checked and deliberately left alone: playback resolves the attached entry's own relative path and only reads, so sharing is invisible to it. Retention's keep_last_per_channel counts two entries on one file as two recordings; that is a policy question, not a correctness one, and deleting either is now safe.