poprhythm
6e93ca6c39
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