yolo/arr
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

Changing a root's path must move the titles under it #236

New Issue
Closed
opened 2026-08-25 10:02:28 +01:00 by naps62-yolo · 1 comment
naps62-yolo commented 2026-08-25 10:02:28 +01:00
Owner
Copy Link
Copy Source

PUT /api/roots/{id} rewrites a root's path and moves nothing, so every title
under that root is mislocated at once. It is the same defect #228 fixed one
level down, but with a wider blast radius: changing a title's root moved one
folder, changing a root's path silently orphans the whole library.

#228 landed crates/arr-api/src/relocate.rs, which already carries the pieces
this needs — plan every rename before performing any, refuse a destination that
exists, undo the renames performed so far if one fails, and rewrite the
media_files rows in the same transaction as the row change. roots::update in
crates/arr-api/src/roots.rs was deliberately left out of #228's scope and was
not touched.

Scope: changing a root's path relocates every title folder under it and
rewrites the media_files rows that point inside it, or the change is refused
and the row is left alone. Reuse relocate.rs rather than writing a second
mover — two implementations of this will drift.

Guards, same as #228: a destination that already holds a folder of that name is
a conflict, not an overwrite; a failed rename leaves the row unchanged; a root
with no titles under it changes path with no filesystem work. Roots are assumed
to share a filesystem, as DESIGN.md §7.4 now states.

Not in scope: changing a root's kind, which is a separate question.

`PUT /api/roots/{id}` rewrites a root's `path` and moves nothing, so every title under that root is mislocated at once. It is the same defect #228 fixed one level down, but with a wider blast radius: changing a title's root moved one folder, changing a root's path silently orphans the whole library. #228 landed `crates/arr-api/src/relocate.rs`, which already carries the pieces this needs — plan every rename before performing any, refuse a destination that exists, undo the renames performed so far if one fails, and rewrite the `media_files` rows in the same transaction as the row change. `roots::update` in `crates/arr-api/src/roots.rs` was deliberately left out of #228's scope and was not touched. Scope: changing a root's `path` relocates every title folder under it and rewrites the `media_files` rows that point inside it, or the change is refused and the row is left alone. Reuse `relocate.rs` rather than writing a second mover — two implementations of this will drift. Guards, same as #228: a destination that already holds a folder of that name is a conflict, not an overwrite; a failed rename leaves the row unchanged; a root with no titles under it changes path with no filesystem work. Roots are assumed to share a filesystem, as DESIGN.md §7.4 now states. Not in scope: changing a root's `kind`, which is a separate question.
naps62-yolo added this to the Feedback pass 2 milestone 2026-08-25 10:02:28 +01:00
naps62-yolo added the area/apidifficulty/moderatetype/bug labels 2026-08-25 10:02:39 +01:00
naps62-yolo commented 2026-08-25 10:20:47 +01:00
Author
Owner
Copy Link
Copy Source

Out of scope here, noticed while implementing this: ApiError::Filesystem renders as files not removed: {error} (crates/arr-api/src/movies.rs:206). That wording predates #228 and was accurate when a failed delete was the only way to reach it. It now also fronts a failed move, so a root whose relocation failed reports files not removed: could not move '/mnt/media/movies/main/Dune (2021)': Permission denied, which reads as the opposite of what happened. A neutral prefix would fix it, but the change lands in movies.rs, outside this issue.

Out of scope here, noticed while implementing this: `ApiError::Filesystem` renders as `files not removed: {error}` (`crates/arr-api/src/movies.rs:206`). That wording predates #228 and was accurate when a failed delete was the only way to reach it. It now also fronts a failed move, so a root whose relocation failed reports `files not removed: could not move '/mnt/media/movies/main/Dune (2021)': Permission denied`, which reads as the opposite of what happened. A neutral prefix would fix it, but the change lands in `movies.rs`, outside this issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
arr-api
 area/ci
CI and test harness
 area/compat
arr-compat
 area/core
arr-core
 area/daemon
arr-daemon
 area/db
arr-db
 area/dl
arr-dl
 area/indexer
arr-indexer
 area/infra
workspace and tooling
 area/meta
arr-meta
 area/parse
arr-parse
 area/probe
arr-probe
 area/subs
arr-subs crate: providers, extraction, translation, sync
 area/web
web/
 difficulty/easy
bounded, obvious approach, few files
 difficulty/hard
subtle correctness or cross-cutting
 difficulty/moderate
multiple files, judgement, an interface to design
 difficulty/trivial
one file, mechanical, no design decisions
 phase/1-skeleton
workspace, CI, config, database, empty API and SPA
 phase/2-logic
parsing and policy engine, pure, no network
 phase/3-sourcing
TMDB and Prowlarr, read-only
 phase/4-movies
movies end to end
 phase/5-ui
search, buckets, library views, queues
 phase/6-tv
seasons, episodes, tracking, derived status
 phase/7-people
owner tags and notifications
 phase/8-compat
Jellyseerr shim
 phase/9-subtitles
build order: subtitles, DESIGN.md §15
 type/bug
type/chore
type/feature
type/test
No labels area/api difficulty/moderate type/bug
Milestone
No items
No Milestone Feedback pass 2
Projects
Clear projects
No projects
Assignees
Clear assignees
hermes (Hermes (agent)) naps62 (Miguel Palhas) naps62-yolo (naps62-yolo (agent))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yolo/arr#236