mirror of
https://github.com/euzu/tuliprox.git
synced 2026-10-13 19:32:36 +02:00
DarkBreakpoint
af679d637d
The previous commit made one file reachable from several library entries. It did not tell the deletion path. `DeletionTarget` still documented "the single file this deletion owns" and unlinked unconditionally, so Alice removing her entry deleted the bytes out from under Bob's -- his entry survived pointing at a path that no longer existed, and his playback started 404ing on a recording he never touched. The repository has carried reference counting since the split, but nothing consulted it on the way to `unlink`. This is the same shape as every other defect in this series: a guard that exists and is tested, wired to nothing. `begin_deletion_authorized` now counts the other entries holding the same media inside the boundary that stamps the task, and `path_to_unlink` returns `None` when there are any. The bytes go when the last entry does. Entries already mid-deletion are deliberately not counted as holders. Two concurrent deletions that each saw the other would both decline to unlink and strand the file with nothing pointing at it, which is the one outcome worse than deleting too eagerly -- it is invisible. Not changed: private quota is still charged per entry at full size, so two users sharing a 4 GB film are each charged 4 GB. That is deliberate. A user's limit must not depend on what strangers happen to record, and the shared pool cannot double-count because two shared entries on one programme land in the same pool and are already deduplicated there.