mirror of
https://github.com/euzu/tuliprox.git
synced 2026-09-24 10:02:29 +02:00
DarkBreakpoint
67d75d7ab4
The documentation described a system that no longer exists, and in two places described the opposite of what the code now does. - The layout section documented `<recording-root>/users/<owner-id>/<rel>` for private recordings and `shared/<rel>` for shared ones. That resolver was deleted: recordings are stored owner-independently at `<recording-root>/<rel>`, because one physical file is shared by every user who asked for it. The organised layouts and the component sanitisation rules are now documented as they are implemented. - The config reference claimed persisted queue recovery "is tolerant of corruption" and "starts with an empty transfer queue instead of aborting server boot". The queue now fails closed: a damaged database is rebuilt from the recovery history, and a database ahead of every surviving history refuses to start. An operator following the old text would have expected silent recovery from a condition that is deliberately fatal. - `download.read` / `download.write` were still listed as grantable permissions after their removal, and `recording.write` after its split. bin/dvr_doctor.sh looked for `downloads_state.json` and summarised it with jq. That file never existed under this name, and the queue it stood for is now a B+Tree, so the section printed "(absent)" and skipped its summary exactly when an operator needed it. It now reports the repository and its recovery generations: the CURRENT pointer, the retained generation pair, journal sizes, the fail-closed case where a database has no history, and a warning when the recovery directory shares a filesystem with the database — which survives a corrupt file but not the loss of the volume it exists to protect against. CHANGELOG records the three breaking changes: the non-migrating queue, the permission split, and the moved recording files.