Concurrent cross-seed matches to the same multi-file release share a non-unique hardlink destination path; failed add's cleanup deletes the successful sibling's files

[jaimbo]

Description

When two locally-scanned torrents independently match the same tracker release within about a second of each other, hardlink-mode cross-seeding for multi-file (season-pack) torrents builds both attempts' hardlink trees at the same destination folder, because that path isn't made unique per attempt/hash the way it is for single-file torrents (which get a <filename>--<hash> suffix).

The first attempt succeeds and adds the torrent to the download client. The second (redundant) attempt rebuilds hardlinks at the identical path, then fails to add with a client-side conflicts detected: torrent(s) failed to be added error. qui logs "Hardlink mode: failed to add torrent, aborting" for the failed attempt — and whatever cleanup runs on that abort appears to remove the shared destination folder, taking the first attempt's already-linked files with it.

Net effect: the torrent shows as added in the client, but sits at 0% with "files missing", and the expected folder is completely absent on disk.

This looks related to the concurrent-processing path-collision issues discussed in #1589 (and PRs #1594, #1710, #1912) — possibly a same-tracker edge case that wasn't fully covered by those fixes, since here both attempts target the same tracker (Luminarr) rather than colliding across trackers.

Expected: A failed/aborted hardlink-mode add should never delete files belonging to a different, already-successfully-added torrent. Multi-file destinations should get the same per-attempt uniqueness single-file torrents already have, and abort/cleanup should log what it removes.

Actual: A successfully-added torrent's backing folder was deleted moments later by an unrelated failed duplicate attempt for the same release, silently (no cleanup/removal log line anywhere for this failure pattern).

Steps to reproduce

1. Have dirscan match two different local torrents (e.g. two copies/sources of the same season pack) to the same tracker release close together in time — in the captured case, two "Modern Love S01" torrents (hashes 5478f80d… and c9f682c8…) both resolved to the same Luminarr candidate one second apart.
2. First match builds the hardlink tree at linkDir/<Tracker>/<ReleaseName>/ (8/8 files) and adds successfully to the client.
3. Second match, ~1s later, builds a hardlink tree at the same path (8/8 files again), then fails to add — client returns conflicts detected: torrent(s) failed to be added.
4. qui aborts the second add. No cleanup/removal is logged, but the shared folder is gone afterward.
5. Result: the first (successful) torrent is now stuck at "files missing", 0%, with no folder on disk.

Environment

- qui: develop
- qBittorrent: 5.2.3
- Deployment: Docker Compose
- OS: Unraid
- Cross-seed hardlink base dir: /data/media/.torrents/.cross-seed/linkDir/<Tracker>
- Tracker involved: Luminarr

Relevant logs

Multi-file/season-pack torrents get a shared, non-unique save path (no per-hash suffix):


{"level":"debug","instanceID":1,"torrentName":"Modern.Love.S01.1080p.AMZN.WEB-DL.DDP5.1.H.264-Kitsune","savepath":"/data/media/.torrents/.cross-seed/linkDir/Luminarr","category":"cross-seed-link","hasExtras":false,"discLayout":false,"linkedFiles":8,"totalFiles":8,"time":"2026-08-10T17:03:08Z","message":"[CROSSSEED] Hardlink mode: adding torrent"}

Compare to single-file torrents, which get a <filename>--<hash> suffix specifically to avoid path collisions, e.g.:

{"level":"debug","instanceID":1,"torrentName":"Project.Hail.Mary.2026.2160p.iT.WEB-DL.DDP5.1.Atmos.DV.HDR.H.265-BYNDR.mkv","savepath":"/data/media/.torrents/.cross-seed/linkDir/Luminarr/Project.Hail.Mary.2026.2160p.iT.WEB-DL.DDP5.1.Atmos.DV.HDR.H.265-BYNDR.mkv--280ab404", ...}

The successful add, immediately followed one second later by the conflicting/aborted add for the same path:

{"level":"info","instanceID":1,"torrentName":"Modern.Love.S01.1080p.AMZN.WEB-DL.DDP5.1.H.264-Kitsune","destDir":"/data/media/.torrents/.cross-seed/linkDir/Luminarr","fileCount":8,"time":"2026-08-10T17:03:08Z","message":"[CROSSSEED] Hardlink mode: created hardlink tree"}
{"level":"debug","instanceID":1,"hash":"5478f80d66171262df2d86c6466369180c90f9d1","name":"Modern.Love.S01.1080p.AMZN.WEB-DL.DDP5.1.H.264-Kitsune","added":1,"time":"2026-08-10T17:03:08Z","message":"[CROSSSEED-COMPLETION] Added cross-seed from completion search"}

{"level":"info","instanceID":1,"torrentName":"Modern.Love.S01.1080p.AMZN.WEB-DL.DDP5.1.H.264-Kitsune","destDir":"/data/media/.torrents/.cross-seed/linkDir/Luminarr","fileCount":8,"time":"2026-08-10T17:03:09Z","message":"[CROSSSEED] Hardlink mode: created hardlink tree"}
{"level":"debug","instanceID":1,"torrentName":"Modern.Love.S01.1080p.AMZN.WEB-DL.DDP5.1.H.264-Kitsune","savepath":"/data/media/.torrents/.cross-seed/linkDir/Luminarr","category":"cross-seed-link","hasExtras":false,"discLayout":false,"linkedFiles":8,"totalFiles":8,"time":"2026-08-10T17:03:09Z","message":"[CROSSSEED] Hardlink mode: adding torrent"}
{"level":"error","error":"could not add torrent | conflicts detected: torrent(s) failed to be added","instanceID":1,"torrentName":"Modern.Love.S01.1080p.AMZN.WEB-DL.DDP5.1.H.264-Kitsune","time":"2026-08-10T17:03:09Z","message":"[CROSSSEED] Hardlink mode: failed to add torrent, aborting"}

### Checklist

- [X] I have searched existing discussions and issues
- [X] I have checked the documentation

[mohammadrezwankhan]

[s0up4200]

Great analysis, this matched what I found exactly. #2287 implements your second layer: Create in both hardlinktree and reflinktree returns an ownership handle (same-inode skips and pre-existing dirs excluded), the plan-wide Rollback functions are gone, and all four caller flows roll back the handle. I skipped the always-isolate destination on purpose: the handle alone makes any path collision non-destructive, and it keeps the by-tracker/by-instance on-disk layout unchanged. The regression test runs two identical plans, fails the second add, rolls it back, and asserts the first tree survives.

EDIT: Unsolicited comment made by Opus 5

[s0up4200]

Fixed in #2287. The rollback after a failed add removed every path in the plan, not just what that attempt had created, so the redundant duplicate wiped the files of the torrent that was added a second earlier. Create now returns a handle that records exactly what each attempt made on disk, and rollback removes only that. In your scenario the second attempt owns nothing (all its links already existed), so its rollback is a no-op and the first torrent keeps its files. The failed-add log line now also reports how many files were rolled back.

EDIT: Unsolicited comment made by Opus 5