qBittorrent moves all existing files to "incomplete" folder after rechecking updated torrent #17492

New issue

Open

opened 2026-02-22 03:51:52 -05:00 by deekerman · 0 comments

deekerman commented

2026-02-22 03:51:52 -05:00

Owner

Originally created by @codinv on GitHub (Feb 2, 2026).

qBittorrent & operating system versions

qBittorrent v5.1.4 in docker on synology nas
image: linuxserver/qbittorrent:latest

What is the problem?

I have a large torrent (~400 GB) that is already fully downloaded. This torrent is periodically updated by the publisher: new files are added and some existing files are modified.
When the torrent is updated, I add the new .torrent file to qBittorrent and let it perform a recheck.
The problem occurs when the option “Keep incomplete torrents in:” is enabled.

Steps to reproduce

Download a large torrent (hundreds of GB) completely.
Enable the option “Keep incomplete torrents in:” and set an incomplete directory.
Later, add an updated version of the same torrent (with additional or modified files).
qBittorrent starts rechecking the data.

Actual behavior
After the recheck finishes:

qBittorrent moves all torrent files (the entire ~400 GB) into the incomplete directory.
Then it downloads the new/modified files.
After completion, all data is moved back to the main save directory.
This results in:
Massive and unnecessary disk I/O
Long delays
Potential wear on storage devices

Expected behavior

After the recheck:

Already downloaded and unchanged files should stay in the main save directory
Only new or modified files should be downloaded into the incomplete directory
After the torrent finishes downloading, only those new/changed files should be moved to the main save directory according to the category settings
In other words, the incomplete folder should be used only for files that are actually incomplete, not for already verified data.

This behavior makes updating large torrents very inefficient
The issue is especially noticeable with torrents that are frequently updated
It would be great if qBittorrent could avoid moving already completed data during rechecks

Additional context

No response

Log(s) & preferences file(s)

Originally created by @codinv on GitHub (Feb 2, 2026). ### qBittorrent & operating system versions qBittorrent v5.1.4 in docker on synology nas image: linuxserver/qbittorrent:latest ### What is the problem? I have a large torrent (~400 GB) that is already fully downloaded. This torrent is periodically updated by the publisher: new files are added and some existing files are modified. When the torrent is updated, I add the new .torrent file to qBittorrent and let it perform a recheck. The problem occurs when the option “Keep incomplete torrents in:” is enabled. ### Steps to reproduce Download a large torrent (hundreds of GB) completely. Enable the option “Keep incomplete torrents in:” and set an incomplete directory. Later, add an updated version of the same torrent (with additional or modified files). qBittorrent starts rechecking the data. Actual behavior After the recheck finishes: - qBittorrent moves all torrent files (the entire ~400 GB) into the incomplete directory. - Then it downloads the new/modified files. - After completion, all data is moved back to the main save directory. This results in: - Massive and unnecessary disk I/O - Long delays - Potential wear on storage devices Expected behavior After the recheck: - Already downloaded and unchanged files should stay in the main save directory - Only new or modified files should be downloaded into the incomplete directory - After the torrent finishes downloading, only those new/changed files should be moved to the main save directory according to the category settings In other words, the incomplete folder should be used only for files that are actually incomplete, not for already verified data. This behavior makes updating large torrents very inefficient The issue is especially noticeable with torrents that are frequently updated It would be great if qBittorrent could avoid moving already completed data during rechecks ### Additional context _No response_ ### Log(s) & preferences file(s) -