fix(engine): never orphan files, and reclaim orphans under the disk cap#3
Merged
Conversation
Two gaps in the disk-retention logic let files survive on disk with nothing
tracking them ("removed from the listing but still on disk"):
1. deleteRecordFiles dropped the record via a deferred call even when the actual
file removal was refused (unsafe name) or failed (I/O) — orphaning the files.
Now the record is dropped ONLY after the files are confirmed gone; a failed or
refused removal keeps the record so the files stay tracked and get retried.
2. The disk cap iterated records, so files with no record (a client "rem", a
delete-without-files, or leftovers from a past run) were invisible and never
reclaimed. enforceDiskCap now reconciles against the actual download folder:
it lists on-disk entries, protects those backed by an active/seeding torrent,
and evicts the oldest inactive item first — records AND untracked orphans —
until back under Disk.MaxGB.
Also: TorrServer "rem" now retires the torrent (cleaned on the normal schedule)
instead of deleting the record and leaving the files behind untracked.
Safety: eviction re-checks the entry isn't active and stays inside the cache dir.
Because the cap reclaims any inactive file under the folder, README warns not to
point FT_CACHE_PATH at a folder shared with other apps.
Tests: keeps-record-on-failure, scanDisk orphan detection.
Verified live: a 1.2 GB orphan (no record) is evicted under a 1 GB cap.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012bj3G2zzqEaALFa8ufbkDJ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problema
Podían quedar archivos huérfanos: "borrado del listado pero sigue en disco". Dos huecos:
deleteRecordFileshuerfanizaba en fallo. Eldeferborraba el record aunque elRemoveAllfallara o el nombre fuera inseguro → archivos sin record.rem, un borrado sin archivos, o históricos) eran invisibles → nunca se recuperaban.Arreglo
enforceDiskCapahora escanea/downloads, protege lo respaldado por un torrent activo/seed vivo, y desaloja lo más viejo primero — records y huérfanos — hasta bajar del tope.remahora retira el torrent (limpieza en el ciclo normal) en vez de borrar el record y dejar los archivos.Seguridad
FT_CACHE_PATHa una carpeta compartida con otras apps.Verificación
KeepsRecordOnFailure(no huerfaniza) yScanDiskFindsOrphans. Backendbuild+vet+testverde.disk cap: evicted orphan (orphan-big), freed 1200MB,/downloadsqueda vacío.🤖 Generated with Claude Code