qbt wrongly overwriting complete file by partial causing data loss

deekerman commented

2026-02-21 19:47:45 -05:00

Owner

Originally created by @slrslr on GitHub (Jun 1, 2019).

qbt 4.1.7 Windows 10

qBittorrent overwiting complete files by incomplete ones causing data loss.

I am giving 3 cases in which i have lost mine downloaded data thanks to this qbt problem:

Two torrents, same save path, both has one identic file in payload, but file having different name.
First torrent download complete and is in paused state, second one is partially downloaded and paused too. In qbt i rename partially downloaded file in first torrent to match completed filename in other torrent (files will be identic when completely downloaded) and complete file gets overwritten by partial - which is wrong, qbt should detect this and keep complete one or ask if i want to overwrite destination file.

Another cases 2 cases where qbt fail to intelligently handle file moving/renaming:

Two different torrents sharing common files. I tick to exclude partialy downloaded file inside one torrent which is in the Downloading state. And then in other torrent (which is paused and not downloaded anything yet) i only tick to download the file i excluded in previous torrent (other files in this torrent are not of my interest).
I see the partial file from first torrent was moved into .unwanted hidden subdirectory.
I unpause second torrent and fully download that file.
Now i go to first torrent and tick back the file which was partialy downloaded.
Qbt will move partialy downloaded file from torrent 1 .unwanted directory to main directory, overwriting completed file of the torrent 2. It should not happen.

I select three torrents that has common payload files and change its category and while these are in Automated management and destination category has different savepath specified, qbt will move these three torrents payload files to different directory. Problem is that it does not do it intelligently - 2 torrents was 0% complete and third was 60% complete. After payload files move (category change), i do recheck of the torrents to find all are 0%. So qbt have not verified file download completness before deciding whether to overwrite the file.

similar problem: #10535

Originally created by @slrslr on GitHub (Jun 1, 2019). qbt 4.1.7 Windows 10 qBittorrent overwiting complete files by incomplete ones causing data loss. I am giving 3 cases in which i have lost mine downloaded data thanks to this qbt problem: 1. Two torrents, same save path, both has one identic file in payload, but file having different name. First torrent download complete and is in paused state, second one is partially downloaded and paused too. **In qbt i rename partially downloaded file in first torrent to match completed filename in other torrent** (files will be identic when completely downloaded) and **complete file gets overwritten by partial** - which is wrong, qbt should detect this and keep complete one or ask if i want to overwrite destination file. Another cases 2 cases where qbt fail to intelligently handle file moving/renaming: 2. Two different torrents sharing common files. I tick to exclude partialy downloaded file inside one torrent which is in the Downloading state. And then in other torrent (which is paused and not downloaded anything yet) i only tick to download the file i excluded in previous torrent (other files in this torrent are not of my interest). I see the partial file from first torrent was moved into .unwanted hidden subdirectory. I unpause second torrent and fully download that file. Now i go to first torrent and tick back the file which was partialy downloaded. **Qbt will move partialy downloaded file from torrent 1 .unwanted directory to main directory, overwriting completed file of the torrent 2.** It should not happen. 3. I select three torrents that has common payload files and change its category and while these are in Automated management and destination category has different savepath specified, qbt will move these three torrents payload files to different directory. Problem is that it does not do it intelligently - **2 torrents was 0% complete and third was 60% complete. After payload files move (category change), i do recheck of the torrents to find all are 0%.** So qbt have not verified file download completness before deciding whether to overwrite the file. similar problem: #10535

deekerman

2026-02-21 19:47:45 -05:00

closed this issue
added the
Duplicate

Data loss
labels

deekerman commented

2026-02-21 19:47:49 -05:00

Author

Owner

@xnoreq commented on GitHub (Jun 2, 2019):

You're not supposed to edit, move, copy or rename the files "under" any torrent client.

If you have to then pause the affected torrents, do your modifications, then re-check (so that qbittorrent can find out what has changed), then resume.

@xnoreq commented on GitHub (Jun 2, 2019): You're not supposed to edit, move, copy or rename the files "under" any torrent client. If you have to then pause the affected torrents, do your modifications, then re-check (so that qbittorrent can find out what has changed), then resume.

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@slrslr commented on GitHub (Jun 2, 2019):

i think more logical would be that qbt will do pausing itself on background than expecting user to do pausing to prevent data loss (which should not happen). Moreover i think the incomplete torrent was paused.

@slrslr commented on GitHub (Jun 2, 2019): i think more logical would be that qbt will do pausing itself on background than expecting user to do pausing to prevent data loss (which should not happen). Moreover i think the incomplete torrent was paused.

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@erasmux commented on GitHub (Jun 2, 2019):

@slrslr

As you wrote in your original message, qbit does not detect this case and it simply renames the file on the disk when you rename a file in the torrent which is perfectly logical and there is nothing "wrong" with this (it would be "wrong" if it didn't). Possibly it could ask if you also want to rename/move the files on the disk like it currently does when deleting torrents.

This should be a "wishlist" request, to add new functionality as this is not a bug (I am not sure if you should just edit the title or open a new issue and mark that as a wishlist).

Personally I don't think it's feasible to detect and automatically resolve such cases in the general case: For example, which file should be selected if both files are incomplete, the first has the first 30% completed and second has the last 65% completed? Or if each torrent had multiple files with the same names in a directory and you rename the directory to match but one torrent has some of the files completed and the other has other files completed? Also what about the case where you rename a file over a different file and they have different contents (I mean if both torrent were completed they would have different contents), how should qbit handle such cases? It makes no sense that a torrent client would even try to tackle these questions.

I do agree it would be nice if qbit asked before overwriting files silently (assuming that is the current behavior). Even "always ask" is not so simple, what about directories? What about directories which contain directories? Do you want only Yes/No or also "All" and maybe "None" (for multiple files)? Do you also want "All in this directory" and so on....

There is still the problematic case where one torrent is active and you try to rename the other over it. Let say qbit torrent asks if you wish to overwrite the existing file and you do select to overwrite but qbit can't overwrite the file since the other torrent is active, what now? (I assume we don't want the old file to be deleted, but should the filename we tried to rename be renamed or not?)

Finally, I think you totally misunderstood @xnoreq, he meant there is a simple workaround for all this and more:

A. Pause/Stop all involved torrents (this is in order to ensure files are not locked and furthermore to ensure qbit does not "see" a state with missing files and decides to changed the torrent to errored or redownload files).
B. Copy/move/rename/delete files as necessary using you favorite file managing program (added benefit I find qbit's moving of files between drives very slow and this is a workaround also for this).
C. Rename/set location/etc. as necessary through the qbit interface. You must make sure the files you rename or move (using set location) do not exist at this point (otherwise qbit will rename/move them and according to what you say also silently overwrite existing files). Assuming they do exist, qbit will not do any disk activity and only update the location qbit believes the files are located.
D. Resume torrents.

I use the above all the time and it totally avoids all the above issues (and more).

@erasmux commented on GitHub (Jun 2, 2019): @slrslr As you wrote in your original message, qbit does not detect this case and it simply renames the file on the disk when you rename a file in the torrent which is perfectly logical and there is nothing "wrong" with this (it would be "wrong" if it didn't). Possibly it could ask if you also want to rename/move the files on the disk like it currently does when deleting torrents. This should be a "wishlist" request, to add new functionality as this is not a bug (I am not sure if you should just edit the title or open a new issue and mark that as a wishlist). Personally I don't think it's feasible to detect and automatically resolve such cases in the general case: For example, which file should be selected if both files are incomplete, the first has the first 30% completed and second has the last 65% completed? Or if each torrent had multiple files with the same names in a directory and you rename the directory to match but one torrent has some of the files completed and the other has other files completed? Also what about the case where you rename a file over a different file and they have different contents (I mean if both torrent were completed they would have different contents), how should qbit handle such cases? It makes no sense that a torrent client would even try to tackle these questions. I do agree it would be nice if qbit asked before overwriting files silently (assuming that is the current behavior). Even "always ask" is not so simple, what about directories? What about directories which contain directories? Do you want only Yes/No or also "All" and maybe "None" (for multiple files)? Do you also want "All in this directory" and so on.... There is still the problematic case where one torrent is active and you try to rename the other over it. Let say qbit torrent asks if you wish to overwrite the existing file and you do select to overwrite but qbit can't overwrite the file since the other torrent is active, what now? (I assume we don't want the old file to be deleted, but should the filename we tried to rename be renamed or not?) Finally, I think you totally misunderstood @xnoreq, he meant there is a simple workaround for all this and more: A. Pause/Stop all involved torrents (this is in order to ensure files are not locked and furthermore to ensure qbit does not "see" a state with missing files and decides to changed the torrent to errored or redownload files). B. Copy/move/rename/delete files as necessary using you favorite file managing program (added benefit I find qbit's moving of files between drives very slow and this is a workaround also for this). C. Rename/set location/etc. as necessary through the qbit interface. You must make sure the files you rename or move (using set location) do not exist at this point (otherwise qbit will rename/move them and according to what you say also silently overwrite existing files). Assuming they do exist, qbit will not do any disk activity and only update the location qbit believes the files are located. D. Resume torrents. I use the above all the time and it totally avoids all the above issues (and more).

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@slrslr commented on GitHub (Sep 6, 2019):

Another accidentally overwitten file (1.4GB), because qbt fails to ask for a confirmation! 😡
It hurs alot to redownload this torrent.

@slrslr commented on GitHub (Sep 6, 2019): Another accidentally overwitten file (1.4GB), because qbt fails to ask for a confirmation! 😡 It hurs alot to redownload this torrent.

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@xnoreq commented on GitHub (Sep 12, 2019):

Besides my previous comment, parts of this cannot be improved in qbittorrent because of limitations in libtorrent.
libtorrent stores resume data and renaming files will "migrate" this state to the new file name.

I tried to describe the steps that would be needed to make just the first scenario work in qbittorrent, but this is insane. It involves pausing, moving torrent files, moving files on disk several times, rescanning (twice in worst case) and resuming.
Each time you rename a file when the target already exists

Two different torrents sharing common files.

This is simply not supported. Probably never will, because this is even more complex and would needed to be implemented in libtorrent anyway.

Don't use torrents that share common files.

@xnoreq commented on GitHub (Sep 12, 2019): Besides my previous comment, parts of this cannot be improved in qbittorrent because of limitations in libtorrent. libtorrent stores resume data and renaming files will "migrate" this state to the new file name. I tried to describe the steps that would be needed to make just the first scenario work in qbittorrent, but this is insane. It involves pausing, moving torrent files, moving files on disk several times, rescanning (twice in worst case) and resuming. Each time you rename a file when the target already exists > Two different torrents sharing common files. This is simply not supported. Probably never will, because this is even more complex and would needed to be implemented in libtorrent anyway. Don't use torrents that share common files.

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@erasmux commented on GitHub (Sep 13, 2019):

Two different torrents sharing common files.

This is simply not supported. Probably never will, because this is even more complex and would needed to be implemented in libtorrent anyway.

Don't use torrents that share common files.

I assume you mean downloading the same file in parallel from two different torrents (which hopefully have the same file contents, but obviously the client can not know this, at least not in the general case). I agree this is crazy and from my limited understanding of the bittorrent protocol I don't see how any client can support this.

The first case the OP stated, "rename partially downloaded file in first torrent to match completed filename in other torrent", is already handled very well in qbittorrent. You just need to first delete the partially downloaded file, then you rename the file to the completed file name (or set location or move/link the completed file, etc.), and then recheck.

Additionally, as opposed to other clients I have used, as long as the torrent is paused, the recheck is 100% safe and can not cause any data loss (this has saved me from data loss in cases which I believed the file contents was the same but it was not).

All in all, I really don't see any problem here. The only improvement that can be had is asking before overwriting existing files (I didn't test this myself, but from what I understand qbit currently overwrites "silently").

@erasmux commented on GitHub (Sep 13, 2019): > > Two different torrents sharing common files. > > This is simply not supported. Probably never will, because this is even more complex and would needed to be implemented in libtorrent anyway. > > Don't use torrents that share common files. I assume you mean downloading the same file in parallel from two different torrents (which hopefully have the same file contents, but obviously the client can not know this, at least not in the general case). I agree this is crazy and from my limited understanding of the bittorrent protocol I don't see how any client can support this. The first case the OP stated, "rename partially downloaded file in first torrent to match completed filename in other torrent", is already handled very well in qbittorrent. You just need to first delete the partially downloaded file, then you rename the file to the completed file name (or set location or move/link the completed file, etc.), and then recheck. Additionally, as opposed to other clients I have used, as long as the torrent is paused, the recheck is 100% safe and can not cause any data loss (this has saved me from data loss in cases which I believed the file contents was the same but it was not). All in all, I really don't see any problem here. The only improvement that can be had is asking before overwriting existing files (I didn't test this myself, but from what I understand qbit currently overwrites "silently").

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@slrslr commented on GitHub (Sep 13, 2019):

You just need to

User shoul should not need to waste the time (if the software can do it on background) and loose ones data because a) accidentaly forgot the payload is common for more torrents b) forgot he need to do it manually because qbt is unable to protect his data stupidly overwriting complete file by incomplete.

asking before overwriting existing files

yes. but better checking payload file size in qbt (unsure if it is defined in bytes for higher probability of doing good decision) and if it is equal for both files and one is incomplete, it should preserve more complete one without asking. If can not be done, then ask user, single click better than lost data.

@slrslr commented on GitHub (Sep 13, 2019): > You just need to User shoul should not need to waste the time (if the software can do it on background) and loose ones data because a) accidentaly forgot the payload is common for more torrents b) forgot he need to do it manually because qbt is unable to protect his data stupidly overwriting complete file by incomplete. > asking before overwriting existing files yes. but better checking payload file size in qbt (unsure if it is defined in bytes for higher probability of doing good decision) and if it is equal for both files and one is incomplete, it should preserve more complete one without asking. If can not be done, then ask user, single click better than lost data.

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@erasmux commented on GitHub (Sep 13, 2019):

User shoul should not need to waste the time (if the software can do it on background) and loose ones data because a) accidentaly forgot the payload is common for more torrents b) forgot he need to do it manually because qbt is unable to protect his data stupidly overwriting complete file by incomplete.

So for example if I downloaded a "complete" version which I found to be corrupted or unsatisfactory, and then I try to download a proper version which by chance has the exact same name, the program should not "waste my time" and refuse to overwrite the corrupted version?

I admit I do not fully understand your use case(s). I am not sure you have a clean understanding of your use case(s) and the exact behavior you want in each case. Like we tried to explain in the general case there could be multiple torrents each with multiple files, with various sizes and different levels of completeness and I think it should be obvious a torrent client should not even try to tackle questions such as which files should "win" over which others.

As far as I know all clients behave exactly like qbit does: If a torrent is unpaused it will overwrite any data in order to complete itself, including truncating files if they have a large size. That is just the way bittorrent clients work and it should be the way users expect clients to work (if only because all clients behave like is, personally I also find it the only logical behavior).

Am I wrong? Can you name a torrent client which behaves differently? Can you detail exactly how it behaves and how it handles the general cases I have detailed above?

yes. but better checking payload file size in qbt (unsure if it is defined in bytes for higher probability of doing good decision) and if it is equal for both files and one is incomplete, it should preserve more complete one without asking. If can not be done, then ask user, single click better than lost data.

The question to overwrite or not to overwrite should be as simple as possible. Personally the only simple solution I see is to check if any file would be overwritten by an operation and if so to ask one yes/no question regarding the entire operation. For example if you choose to set location, and there is even one conflicting file, you may choose to explicitly overwrite (like it does silently today) or cancel the whole operation. Obviously you always have the flexibility to untangle such messes as you see fit using the file manager of your choice and only then pointing qbit at the right location (after you get use to this, it is really easy and actually saves you time and unnecessary redownloading).

Like I detailed above, I do not see how in the general case qbit can make any rational decision based on file sizes (for example one torrent has 90% of 10M while the other has 10% of 20M, which one wins? what if your are renaming a "proper" over a nuked version and by the chance the proper is smaller, does the nuked version really win? etc.).

@erasmux commented on GitHub (Sep 13, 2019): > User shoul should not need to waste the time (if the software can do it on background) and loose ones data because a) accidentaly forgot the payload is common for more torrents b) forgot he need to do it manually because qbt is unable to protect his data stupidly overwriting complete file by incomplete. So for example if I downloaded a "complete" version which I found to be corrupted or unsatisfactory, and then I try to download a proper version which by chance has the exact same name, the program should not "waste my time" and refuse to overwrite the corrupted version? I admit I do not fully understand your use case(s). I am not sure you have a _clean_ understanding of your use case(s) and the exact behavior you want in each case. Like we tried to explain in the general case there could be multiple torrents each with multiple files, with various sizes and different levels of completeness and I think it should be obvious a torrent client should not even try to tackle questions such as which files should "win" over which others. As far as I know all clients behave exactly like qbit does: If a torrent is unpaused it will overwrite any data in order to complete itself, including truncating files if they have a large size. That is just the way bittorrent clients work and it should be the way users expect clients to work (if only because all clients behave like is, personally I also find it the only logical behavior). Am I wrong? Can you name a torrent client which behaves differently? Can you detail exactly how it behaves and how it handles the general cases I have detailed above? > yes. but better checking payload file size in qbt (unsure if it is defined in bytes for higher probability of doing good decision) and if it is equal for both files and one is incomplete, it should preserve more complete one without asking. If can not be done, then ask user, single click better than lost data. The question to overwrite or not to overwrite should be as simple as possible. Personally the only _simple_ solution I see is to check if any file would be overwritten by an operation and if so to ask one yes/no question regarding the entire operation. For example if you choose to set location, and there is even one conflicting file, you may choose to explicitly overwrite (like it does silently today) or cancel the whole operation. Obviously you always have the flexibility to untangle such messes as you see fit using the file manager of your choice and only then pointing qbit at the right location (after you get use to this, it is really easy and actually saves you time and unnecessary redownloading). Like I detailed above, I do not see how in the general case qbit can make any rational decision based on file sizes (for example one torrent has 90% of 10M while the other has 10% of 20M, which one wins? what if your are renaming a "proper" over a nuked version and by the chance the proper is smaller, does the nuked version really win? etc.).

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@slrslr commented on GitHub (Sep 13, 2019):

to check if any file would be overwritten by an operation and if so to ask one yes/no question regarding the entire operation

yes please. qbt should display both file sizes and if possible level of completness. Later, if someone will find a lightweight solution to make qbt handle the things reliably on background without asking that would be more proferred

@slrslr commented on GitHub (Sep 13, 2019): > to check if any file would be overwritten by an operation and if so to ask one yes/no question regarding the entire operation yes please. qbt should display both file sizes and if possible level of completness. Later, if someone will find a lightweight solution to make qbt handle the things reliably on background without asking that would be more proferred

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@xnoreq commented on GitHub (Sep 13, 2019):

qbt should display both file sizes

There may not even be 2 files but libtorrent (which qbitorrent uses) may still truncate/overwrite files.
This is because libtorrent stores per-torrent resume data.

This is also why asking a yes/no question may not even be possible in every case where data could get overwritten, because in some cases it would not be triggered by a user operation but by an operation that libtorrent does automatically, in the background.

if possible level of completness

As I've explained above, this would be very complex to implement in qbittorrent and would take a lot of time for each rename.

Maybe you should look for/report this issue in the libtorrent tracker as well.

@xnoreq commented on GitHub (Sep 13, 2019): > qbt should display both file sizes There may not even be 2 files but libtorrent (which qbitorrent uses) may still truncate/overwrite files. This is because libtorrent stores per-torrent resume data. This is also why asking a yes/no question may not even be possible in every case where data could get overwritten, because in some cases it would not be triggered by a user operation but by an operation that libtorrent does automatically, in the background. > if possible level of completness As I've explained above, this would be very complex to implement in qbittorrent and would take a lot of time for each rename. Maybe you should look for/report this issue in the libtorrent tracker as well.

deekerman commented

2026-02-21 19:47:52 -05:00

Author

Owner

@thalieht commented on GitHub (Sep 13, 2020):

Duplicate of #127

@thalieht commented on GitHub (Sep 13, 2020): Duplicate of #127

Rows
Columns

qbt wrongly overwriting complete file by partial causing data loss #8759