Dir Scan doesn't rename/ handle directories like regular scan

[mokahless]

Description

The regular scan seems to rename things properly to what exists on disk (dunno if this is through sonarr/radarr or by reading disk location from qbittorrent?) and even works great between cross-seed torrents that do and don't use a directory structure. Dir Scan doesn't do this though, leaving a ton of errored torrents I have to manually set the directory name/file name for and force recheck. Seems to me it has access to the information it needs to be able to do this, though.

Steps to reproduce

Turn on dir access, radarr/sonarr API. Select a dir scan directory/options (enable start torrents paused), then hit play icon.

Any torrent that uses a top directory instead of just the file will require it to be manually renamed and rechecked. Any torrent with slightly differing filenames from what's on disk also requires this to be renamed and rechecked.

To be clear, it does handle correctly which "set location" it should be under, it just doesn't rename the torrent directory name to match the subdirectory on disk.

Environment

qui 1.14.1
qbittorrent 5.1.4
docker
Debian

Relevant logs

Logs don't seem to detail this aspect.

Checklist

• I have searched existing discussions and issues
• I have checked the documentation

[monologue7959]

Confirming this still reproduces on current versions.

Environment

• qui v1.22.0 (revision b563d4bea9f3709cf284b6a91ee02c4fcd9287fc)
• qBittorrent v5.2.2
• Docker on Unraid
• Dir Scan in regular/reuse mode with local filesystem access
• The relevant paths are mounted identically in the qui and qBittorrent containers

Reproduction

1. Scan a directory shaped like /data/linux-isos/Linux Distribution/Release 01/*.iso.
2. Match a multi-file torrent whose payload paths are Linux.Distribution.Release.01/*.iso.
3. Dir Scan reports a perfect 100% piece match and injects the torrent successfully.
4. qBittorrent immediately reports Missing Files because the torrent's top-level directory remains Linux.Distribution.Release.01 instead of being aligned to the existing Release 01 directory.
5. Rename only that top-level directory to Release 01 in qBittorrent and force a recheck. The torrent completes at 100% without downloading anything.

Sanitized log excerpt:

{"level":"info","directoryID":"<redacted>","runID":"<redacted>","name":"Linux Distribution Release 01","torrent":"Linux.Distribution.Release.01","hash":"<redacted>","perfect":true,"partial":false,"matchRatio":1,"pieceMatchPercent":100,"message":"dirscan: found match"}
{"level":"info","directoryID":"<redacted>","runID":"<redacted>","name":"Linux Distribution Release 01","success":true,"message":"dirscan: injected torrent"}

Useful controls from the same setup:

• Rootless single-file ISO torrents complete normally.
• A rootless torrent containing linux-distribution.iso completes normally.
• A torrent containing the same ISO as Linux.Distribution.Release/linux-distribution.iso enters Missing Files.

This isolates the failure to post-match top-level path alignment rather than mount visibility or content matching. The behavior reproduces in regular/reuse mode.

[s0up4200]

Ive opened a PR to try and address this issue here: #2113

It can be tested with docker by pulling the pr-2113 image.

@mokahless @monologue7959