Seed after *arr imports - Automatic hardlink/reflinking on move

[epheterson]

I built a small tool that solves a long-standing pain point in the *arr + qBittorrent workflow: continuing to seed after Sonarr/Radarr moves your files, without duplicating disk space.

The problem

When Sonarr/Radarr imports a completed download, you have two bad options:

• Copy mode: File is duplicated. Seeding continues, but you're burning disk space until you manually clean up the torrent.
• Move mode: File is moved to the media library. qBit loses it and stops seeding.

Sonarr's built-in hardlink support creates the link at the destination (media library → download dir), which means the download dir copy is the "real" one and can't be cleaned up while seeding.

This problem has been discussed many times:

• Match renamed/moved files with their torrents #19987 — Match renamed/moved files with their torrents
• Locate downloaded files for seeding #17740 — Locate downloaded files for seeding
• Support seeding even for torrents with "Missing Files" #17551 — Support seeding even for torrents with "Missing Files"
• How to move a seeding file into a subfolder and continue seeding? #15690 — How to move a seeding file and continue seeding?

Tools like qbt-file-matcher handle the manual case (rename files in qBit after you've reorganized), but don't automate the *arr import flow.

The approach: relinkarr

Instead of modifying qBittorrent internals, this runs as a sidecar container that:

1. Polls qBit API for all seeding/stalledUP torrents and their file paths
2. Records each file's inode and size when first seen
3. Detects when a file goes missing (moved by Sonarr/Radarr)
4. Finds the file at its new location by scanning media directories — first by inode (same filesystem), then by exact file size (cross-filesystem)
5. Creates a hardlink at the original download path → same data blocks, zero disk usage
6. Falls back to Btrfs/XFS reflink (cp --reflink=always) for cross-subvolume setups (common on Synology NAS where each shared folder is a separate Btrfs subvolume) — also zero additional disk

When you're done seeding and delete the torrent with files, only the hardlink/reflink is removed. The media library copy is untouched.

1. qBit downloads:       /downloads/Pack/episode.mkv  (inode 12345)
2. Sonarr moves to:      /tv/Show/Season 1/S01E01.mkv (same inode or new)
3. relinkarr detects:    /downloads/Pack/episode.mkv is missing
4. relinkarr finds:      file at /tv/Show/Season 1/S01E01.mkv (by inode or size)
5. relinkarr hardlinks:  /downloads/Pack/episode.mkv → same data blocks
6. qBit keeps seeding:   file at original path ✓
7. Delete torrent:       hardlink removed, media library copy persists ✓

Where it stands

This whole thing has been built with Claude Code, mostly voice dictation so far, from the initial idea through the working prototype, NAS testing, and yes, it also wrote this post, with me. The code works (connects to qBit, tracks files, detects moves, matches by inode/size, creates hardlinks with reflink fallback), but I've only tested it on my own Synology setup and hit the cross-subvolume Docker mount issue that I'm sure others would run into too. It'll be fleshed out, tested, reviewed and maintained but all me and my AI, it'd be cool to work with collaborators who have contributed to qBit/libtorrent and do this right.

Questions

1. Does anything like this already exist? I looked around and found qbt-file-matcher for manual reorganization, but nothing that automates the *arr import flow specifically. Am I missing something?
2. Does this approach make sense? Polling the qBit API, matching by inode/size, restoring hardlinks/reflinks at the original path — is there a better way to do this, or obvious problems I'm not seeing?
3. Would anyone actually use this? If not, what would make it more useful? Different matching strategy, different integration points, different deployment model?
4. Should this be integrated directly into qBit instead? libtorrent already has rename_file() — a native "follow the file" feature that watches for moves and updates the internal mapping would be cleaner than an external sidecar. Would anyone want to collaborate on that, or is the standalone tool the right call?

Once it's more polished I'll put up a repo and update with a link.

---

References:

• TRaSH Guides on hardlinks: https://trash-guides.info/Hardlinks/Hardlinks-and-Instant-Moves/
• libtorrent rename_file: https://www.libtorrent.org/reference-Torrent_Handle.html#rename-file
• qbt-file-matcher (manual matching): https://github.com/xob0t/qbt-file-matcher

[epheterson]

Repo is live: https://github.com/epheterson/relinkarr

Solution was more elegant than I expected, and it's aligned well with the *arr stack. Would be great for some seasoned devs to take a look and give any feedback. Either way, it's working great on my setup saving space automatically!