Category's incomplete Save path prevents Recheck to find files in destination Save path #15412

New issue

Open

opened 2026-02-22 02:06:22 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-22 02:06:22 -05:00

Owner

Originally created by @slrslr on GitHub (Jan 22, 2024).

qBittorrent & operating system versions

qbt 4.6.2 AppImage Linux
Qt: 6.6.1
Libtorrent: 2.0.9.0
Boost: 1.83.0
OpenSSL: 1.1.1w
zlib: 1.2.11

What is the problem?

I have created a new subcategory where i have defined the save path for incomplete files inside this subcategory settings.
Then i have assigned several torrents to this category.
Completed download of 1st torrent. And the files was relocated from incomplete to complete Save Path. Good.
Then renamed payload files of remaining torrents which were 0% complete, so these match 1st completed torrent save paths and payload names.
Recheck not found any data. I expected it would not only check incomplete but also complete save path.
So for the 2nd, 3rd torrents I have picked "Set location" option to define save path where 1st torrent files are (which removed Automatic torrent management). Recheck still does not find anything, even path is identical with 1st torrent. Double-clicking payload file of 2nd, 3rd torrent does not open it in media player, yet clicking to open target folder opens an incomplete save path instead of complete save path, despite i did "Set location" and selected complete save path.

Workaround was to make symbolic link of the 1st torrent (100% complete) payload folder to incomplete save path. Then Recheck found 100% data, and i have enabled again automatic torrent management. Torrent now points complete save path and symlink could be removed. Problem was that when i have symlinked the complete file directly, qbt replaced the complete file with the symlink after recheck without asking so i have lost the data, yet that is another, 11 years unfixed issue number 127.

How it may work better: Recheck may not check data just inside the incomplete save path, but also in complete save path and if complete one has more % completed data, maybe it can remove data from incomplete path and switch to complete path.

If not like i mentioned, then IMO there should be an intuitive way for the user to relocate save path (override category's incomplete save path) and recheck data on newly selected path.

Originally created by @slrslr on GitHub (Jan 22, 2024). ### qBittorrent & operating system versions qbt 4.6.2 AppImage Linux Qt: 6.6.1 Libtorrent: 2.0.9.0 Boost: 1.83.0 OpenSSL: 1.1.1w zlib: 1.2.11 ### What is the problem? I have created a new subcategory where i have defined the save path for incomplete files inside this subcategory settings. Then i have assigned several torrents to this category. Completed download of 1st torrent. And the files was relocated from incomplete to complete Save Path. Good. Then renamed payload files of remaining torrents which were 0% complete, so these match 1st completed torrent save paths and payload names. Recheck not found any data. I expected it would not only check incomplete but also complete save path. So for the 2nd, 3rd torrents I have picked "Set location" option to define save path where 1st torrent files are (which removed Automatic torrent management). Recheck still does not find anything, even path is identical with 1st torrent. Double-clicking payload file of 2nd, 3rd torrent does not open it in media player, yet clicking to open target folder opens an incomplete save path instead of complete save path, despite i did "Set location" and selected complete save path. Workaround was to make symbolic link of the 1st torrent (100% complete) payload folder to incomplete save path. Then Recheck found 100% data, and i have enabled again automatic torrent management. Torrent now points complete save path and symlink could be removed. Problem was that when i have symlinked the complete file directly, qbt replaced the complete file with the symlink after recheck without asking so i have lost the data, yet that is another, 11 years unfixed issue number 127. **How it may work better**: Recheck may not check data just inside the incomplete save path, but also in complete save path and if complete one has more % completed data, maybe it can remove data from incomplete path and switch to complete path. If not like i mentioned, then IMO there should be an intuitive way for the user to relocate save path (override category's incomplete save path) and recheck data on newly selected path.

deekerman added the

Temp folder

label

2026-02-22 02:06:22 -05:00

deekerman commented

2026-02-22 02:06:27 -05:00

Author

Owner

@Jorsher commented on GitHub (Mar 30, 2024):

Would like to add my support to this.

I just spent an embarrassingly big number of minutes trying to figure out why some torrents that were most-definitely at the save path weren't being found by qBittorrent. Eventually, I realized I had the "incomplete torrents" folder set, and that qBit was checking at this temporary location and not the save path I had set. Disabled the 'incomplete torrents' folder and unfortunately it overwrote some of my completed files with the empty incomplete ones...

Anyway, it would be great if any rechecks checked both the incomplete path, and the save path.

@Jorsher commented on GitHub (Mar 30, 2024): Would like to add my support to this. I just spent an embarrassingly big number of minutes trying to figure out why some torrents that were most-definitely at the save path weren't being found by qBittorrent. Eventually, I realized I had the "incomplete torrents" folder set, and that qBit was checking at this temporary location and not the save path I had set. Disabled the 'incomplete torrents' folder and unfortunately it overwrote some of my completed files with the empty incomplete ones... Anyway, it would be great if any rechecks checked both the incomplete path, and the save path.

deekerman commented

2026-02-22 02:06:29 -05:00

Author

Owner

@AndrewDDavis commented on GitHub (Apr 30, 2025):

Definitely, this has recently caused data loss for me too, when trying to troubleshoot a situation where force-recheck wasn't finding the files. Related to (#22188).

@AndrewDDavis commented on GitHub (Apr 30, 2025): Definitely, this has recently caused data loss for me too, when trying to troubleshoot a situation where force-recheck wasn't finding the files. Related to (#22188).