Root cause of the data-loss incident: repeated manual re-triggering
(stop/setLocation/recheck called multiple times across separate
debugging invocations) raced against qBittorrent's own automatic
incomplete-file management. The 7 clean successes earlier all
completed in one uninterrupted pass; the 2 that failed were the ones
manually re-triggered while investigating.
Redesign: the whole operation is now one blocking pass (stop ->
relocate -> rename -> recheck -> poll to completion -> verify ->
report) with a hard rule never to call recheck/stop/setLocation
against the same hash a second time while a previous run might
still be settling. Adds:
- A pre-flight filesystem manifest (name+size) of the destination,
and a post-recheck comparison against it - the real ground-truth
safety net, independent of trusting qBittorrent's self-reported
state.
- Idempotency: skips already-correctly-relinked torrents rather
than re-touching them. Found and fixed a real gap here during
testing - the first version trusted qBittorrent's per-file
"progress" alone, which can be stale (cached from before a move)
and produced a false "already good" on a torrent whose recheck
had never actually run at the new location. Now also requires the
tracked filenames to match the destination manifest.
- setLocation/setDownloadPath verification now polls briefly instead
of checking once immediately - both are asynchronous and a single
immediate check can read stale data (this exact bug false-failed
a real run during testing).
- Fixed manifest generation to use printf instead of `stat -c`'s own
\t escape handling, which silently emitted a literal backslash-t
instead of a real tab and broke `cut -f1` pairing.
Verified end-to-end against a real torrent (Babylon 5 S04, 69GB):
clean single-pass recheck, post-check confirmed all 22 files intact.
Claude-Session: https://claude.ai/code/session_01HZQK6jHmdTpFjFZM8FUnqA
in qbt-relink.sh
Second live incident in the same batch: setLocation genuinely
succeeded and save_path updated correctly, but content_path (what
recheck actually reads) stayed pointed at qBittorrent's incomplete
staging path via a leftover per-torrent download_path override from
an earlier failed attempt. setLocation doesn't clear that override.
Fixed by also calling torrents/setDownloadPath (note: takes "id",
not "hashes") and verifying content_path directly before proceeding.
Also replaced alphabetical-sort file pairing with SxxEyy-parsed
matching, since sort order silently breaks on non-zero-padded
episode numbers (E9 sorts after E10) - a real risk across the
~320 remaining folders with inconsistent naming conventions.
Claude-Session: https://claude.ai/code/session_01HZQK6jHmdTpFjFZM8FUnqA
let a torrent start re-downloading
Batch-relinking 9 torrents, one setLocation call silently failed
(status ignored) while the script declared success and moved on.
Its recheck then ran against the original (now-empty) path, found
0% match, and qBittorrent started re-downloading the whole torrent
from scratch into its incomplete-files staging area. No lasting
harm (separate path from the real hardlinked copy, cleaned up), but
caught only by watching qBittorrent directly, not by anything the
script reported.
Fixes: every mutating call now goes through an api_call() helper
that checks the HTTP status and aborts on failure; the torrent is
stopped before any location/rename calls (qBittorrent 5.x renamed
pause/resume to stop/start) and left stopped after recheck rather
than auto-resuming, so a bad relink can never turn into an active
download. setLocation's effect is also verified via a follow-up
GET before proceeding to renameFile.
Claude-Session: https://claude.ai/code/session_01HZQK6jHmdTpFjFZM8FUnqA
Sonarr's hardlink-import removes files from their original
torrent-named folder, but qBittorrent's own records still point
there - the next recheck or peer request flips those downloads to
"missing files". qbt-relink.sh re-points a torrent's location and
per-file names at the Sonarr-organized destination and triggers a
recheck, so seeding continues against the same underlying data
(same inode) instead of erroring out or needing a re-download.
Documented as a required step in the sonarr skill's per-show
migration workflow.
Claude-Session: https://claude.ai/code/session_01HZQK6jHmdTpFjFZM8FUnqA
poprhythm