qBittorrent 4.1.9.1 is unable to re-check and restarts partially/completed downloads if you re-add a torrent.

deekerman commented

2026-02-21 20:07:06 -05:00

Owner

Originally created by @ezxpro on GitHub (Nov 16, 2019).

qBittorrent version and Operating System

4.1.9.1 Windows 10 x64 (10.0.1xxxx)

If on linux, libtorrent-rasterbar and Qt version

(type here)

What is the problem

qBittorrent 4.1.9.1 recommences partly or complete downloaded torrents upon removing and re-adding them to the list (I made sure I was setting it to download in the same folder as before).

After having this issues, I tried other torrent clients that I know could continue the downloads started by qbittorrent, but I found out qbittorrent had really messed them up, so the alternative client would recheck and start from where qbittorrent left of, namely, from the beginning, since it somehow erased all progress previously made. (In other words, the altenative clients did their job right, but qbittorrent had already messed up)

What is the expected behavior

Upon re-adding a torrent that was already completed or being downloaded and selecting the same download folder, it is expected a re-check will take place and already downloaded pieces will be retained.

Steps to reproduce

Right click a torrent that is
a. currently being downloaded or
b. is already downloaded (the bug happenned to me in both these scenarios)
Select the "delete" option
3, Uncheck (if checked) the checkbox that causes files to be deleted from disk.
4.Re-add torrent (either through torrent file or magnet link, I tried them both and had the same result)
Choose the folder where the partial/completed downloads are.
See that qBittorrent doesn't re-check, but rather starts downloading again, losing all pieces previously downloaded.

Extra info(if any)

Before having this problem, I was on qBittorrent 4.1.8, that I was using since the first day it was released. Today, when I turned my computer up and opened qBittorrent, all torrents disappeared, although I could see the completed/seeding ones in the "all" section of the status bar. My downloading torrents, however, didn't show up at all, so I closed qbittorrent and relaunched it and then my torrents were all there again, however, the downloading torrents would now show up under the "completed" section and the progress bar would show as empty and with 0%
progress. I also checked that all downloaded pieces were there in the torrent statuses, so I performed a re-check on these torrents, but they would still appear under the "completed" section and refuse to continue downloading.

I also restarted qbittorrent 4.1.8 several times and performed several re-checks on these torrents, tried force-starting them, but had no results.

Therefore, I decided to de-install version 4.1.8 and installed version 4.1.9.1 and the problem persisted, so I decided to remove and re-add the torrents and found out that qbittorrent 4.1.9.1 is actually unable to recheck and resume torrents when you remove and re-add them. I did it with only two of my torrents, and in both cases it messes up and re-starts the torernt.

Originally created by @ezxpro on GitHub (Nov 16, 2019). ### qBittorrent version and Operating System 4.1.9.1 Windows 10 x64 (10.0.1xxxx) ### If on linux, libtorrent-rasterbar and Qt version (type here) ### What is the problem qBittorrent 4.1.9.1 recommences partly or complete downloaded torrents upon removing and re-adding them to the list (I made sure I was setting it to download in the same folder as before). After having this issues, I tried other torrent clients that I know could continue the downloads started by qbittorrent, but I found out qbittorrent had really messed them up, so the alternative client would recheck and start from where qbittorrent left of, namely, from the beginning, since it somehow erased all progress previously made. (In other words, the altenative clients did their job right, but qbittorrent had already messed up) ### What is the expected behavior Upon re-adding a torrent that was already completed or being downloaded and selecting the same download folder, it is expected a re-check will take place and already downloaded pieces will be retained. ### Steps to reproduce 1. Right click a torrent that is a. currently being downloaded or b. is already downloaded (the bug happenned to me in both these scenarios) 2. Select the "delete" option 3, Uncheck (if checked) the checkbox that causes files to be deleted from disk. 4.Re-add torrent (either through torrent file or magnet link, I tried them both and had the same result) 5. Choose the folder where the partial/completed downloads are. 6. See that qBittorrent doesn't re-check, but rather starts downloading again, losing all pieces previously downloaded. ### Extra info(if any) Before having this problem, I was on qBittorrent 4.1.8, that I was using since the first day it was released. Today, when I turned my computer up and opened qBittorrent, all torrents disappeared, although I could see the completed/seeding ones in the "all" section of the status bar. My downloading torrents, however, didn't show up at all, so I closed qbittorrent and relaunched it and then my torrents were all there again, however, the downloading torrents would now show up under the "completed" section and the progress bar would show as empty and with 0% progress. I also checked that all downloaded pieces were there in the torrent statuses, so I performed a re-check on these torrents, but they would still appear under the "completed" section and refuse to continue downloading. I also restarted qbittorrent 4.1.8 several times and performed several re-checks on these torrents, tried force-starting them, but had no results. Therefore, I decided to de-install version 4.1.8 and installed version 4.1.9.1 and the problem persisted, so I decided to remove and re-add the torrents and found out that qbittorrent 4.1.9.1 is actually unable to recheck and resume torrents when you remove and re-add them. I did it with only two of my torrents, and in both cases it messes up and re-starts the torernt.

deekerman

2026-02-21 20:07:06 -05:00

closed this issue
added the
Data loss
label

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@0xjmux commented on GitHub (Nov 18, 2019):

I am also experiencing this exact same problem.

In my case, I paused the torrent due to disconnecting from a network, and when I came back to restart it later, qBitTorrent threw an IO error. Even with a force recheck, qBitTorrent is unable to find the files.
The directory the files are being downloaded into hasn't changed, and even with me changing it to a different directory and changing it back (a fix I saw for an older bug online) it still will not find the partially completed torrent.
In my case it was a rather large torrent (200+gb), and it was about halfway downloaded, but I don't know if that is a contributor to the problem or not.

@0xjmux commented on GitHub (Nov 18, 2019): I am also experiencing this exact same problem. In my case, I paused the torrent due to disconnecting from a network, and when I came back to restart it later, qBitTorrent threw an IO error. Even with a force recheck, qBitTorrent is unable to find the files. The directory the files are being downloaded into hasn't changed, and even with me changing it to a different directory and changing it back (a fix I saw for an older bug online) it still will not find the partially completed torrent. In my case it was a rather large torrent (200+gb), and it was about halfway downloaded, but I don't know if that is a contributor to the problem or not.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@Seeker2 commented on GitHub (Nov 18, 2019):

I had a vaguely similar problem back in 2013:
https://github.com/qbittorrent/qBittorrent/issues/684#issuecomment-20799222
An automatic move-on-finish of the torrent by qBitTorrent might partially be to blame for my problem...or be completely unrelated!

@Seeker2 commented on GitHub (Nov 18, 2019): I had a vaguely similar problem back in 2013: https://github.com/qbittorrent/qBittorrent/issues/684#issuecomment-20799222 An automatic move-on-finish of the torrent by qBitTorrent might partially be to blame for my problem...or be completely unrelated!

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@ezxpro commented on GitHub (Nov 18, 2019):

I am also experiencing this exact same problem.

In my case, I paused the torrent due to disconnecting from a network, and when I came back to restart it later, qBitTorrent threw an IO error. Even with a force recheck, qBitTorrent is unable to find the files.
The directory the files are being downloaded into hasn't changed, and even with me changing it to a different directory and changing it back (a fix I saw for an older bug online) it still will not find the partially completed torrent.
In my case it was a rather large torrent (200+gb), and it was about halfway downloaded, but I don't know if that is a contributor to the problem or not.

I lost a 25GB download. Wouldn't be a problem if it didn't have only one or two very slow seeds.
I'm using Vuze instead of qBitTorrent now. Last time I used Vuze it had just been released and I didn't like it. But now it is much better.

@ezxpro commented on GitHub (Nov 18, 2019): > > > I am also experiencing this exact same problem. > > In my case, I paused the torrent due to disconnecting from a network, and when I came back to restart it later, qBitTorrent threw an IO error. Even with a force recheck, qBitTorrent is unable to find the files. > The directory the files are being downloaded into hasn't changed, and even with me changing it to a different directory and changing it back (a fix I saw for an older bug online) it still will not find the partially completed torrent. > In my case it was a rather large torrent (200+gb), and it was about halfway downloaded, but I don't know if that is a contributor to the problem or not. I lost a 25GB download. Wouldn't be a problem if it didn't have only one or two very slow seeds. I'm using Vuze instead of qBitTorrent now. Last time I used Vuze it had just been released and I didn't like it. But now it is much better.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@Kolcha commented on GitHub (Nov 19, 2019):

data loss after re-adding very often is observed when "append !qB extension" option is enabled. with this option disabled have no issues with re-adding.

@Kolcha commented on GitHub (Nov 19, 2019): data loss after re-adding very often is observed when "append !qB extension" option is enabled. with this option disabled have no issues with re-adding.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@0xjmux commented on GitHub (Nov 24, 2019):

Kolcha The "append !qB extension" setting has never been enabled on my machine. I've verified that the setting is disabled, and qBitTorrent still can't find the already downloaded files.

@0xjmux commented on GitHub (Nov 24, 2019): Kolcha The "append !qB extension" setting has never been enabled on my machine. I've verified that the setting is disabled, and qBitTorrent still can't find the already downloaded files.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@ezxpro commented on GitHub (Nov 27, 2019):

data loss after re-adding very often is observed when "append !qB extension" option is enabled. with this option disabled have no issues with re-adding.

Where does one disable/enable this setting?

By the way, I've never fiddled with any such setting before having the issue herein reported.

@ezxpro commented on GitHub (Nov 27, 2019): > > > data loss after re-adding very often is observed when "append !qB extension" option is enabled. with this option disabled have no issues with re-adding. Where does one disable/enable this setting? By the way, I've never fiddled with any such setting before having the issue herein reported.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@Kolcha commented on GitHub (Nov 28, 2019):

open settings dialog, go to "Downloads" page, find checkbox called "Append .!qB extension to incomplete files".

@Kolcha commented on GitHub (Nov 28, 2019): open settings dialog, go to "Downloads" page, find checkbox called "Append .!qB extension to incomplete files".

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@ezxpro commented on GitHub (Nov 28, 2019):

open settings dialog, go to "Downloads" page, find checkbox called "Append .!qB extension to incomplete files".

This feature was disabled, yet I had this Data Loss.

@ezxpro commented on GitHub (Nov 28, 2019): > > > open settings dialog, go to "Downloads" page, find checkbox called "Append .!qB extension to incomplete files". This feature was disabled, yet I had this Data Loss.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@jenxi commented on GitHub (Jan 9, 2020):

I'm on version 4.2.1 and I'm having this issue as well. I suddenly have the I/O error and now all my seeds are restarting from 0%. Force recheck does not resolve this issue.

@jenxi commented on GitHub (Jan 9, 2020): I'm on version 4.2.1 and I'm having this issue as well. I suddenly have the I/O error and now all my seeds are restarting from 0%. Force recheck does not resolve this issue.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@dimitarvp commented on GitHub (Jan 18, 2020):

I still have one fairly small torrent (~6GB) that starts downloading and fails with an I/O error, every time on startup, and refuses to resume until I restart the client. Never even gets to 0.1%.

It uses the same disk all others do, the disk is thoroughly checked and has zero defective sectors (trust me it took a while to check such a huge drive!), all settings seem very generours -- big disk caches, a lot of upload slots, unlimited speed, uTP + TCP are used, Encryption is not enforced, etc. I can't see anything that would cause the issue (I even read the docs of the libtorrent settings and mine seemed default and sane).

@dimitarvp commented on GitHub (Jan 18, 2020): I still have one fairly small torrent (~6GB) that starts downloading and fails with an I/O error, every time on startup, and refuses to resume until I restart the client. Never even gets to 0.1%. It uses the same disk all others do, the disk is thoroughly checked and has zero defective sectors (trust me it took a while to check such a huge drive!), all settings _seem_ very generours -- big disk caches, a lot of upload slots, unlimited speed, uTP + TCP are used, Encryption is not enforced, etc. I can't see anything that would cause the issue (I even read the docs of the libtorrent settings and mine seemed default and sane).

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@Seeker2 commented on GitHub (Jan 18, 2020):

You getting lots of piece fails in qBitTorrent's logger?

A big disk cache can cause an I/O error in qBitTorrent due to its 32bit nature...assuming that's the error you're having.

@Seeker2 commented on GitHub (Jan 18, 2020): You getting lots of piece fails in qBitTorrent's logger? A big disk cache can cause an I/O error in qBitTorrent due to its 32bit nature...assuming that's the error you're having.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@dimitarvp commented on GitHub (Feb 13, 2020):

@Seeker2 here's what I am getting today again:

2020 02 13 19:26 - File error alert. Torrent: &quot;<torrent_name>&quot;. File: &quot;/anonymised/path&quot;. Reason: <torrent_name> file_fallocate (/anonymised/path) error: Operation not supported

I swapped out real values with /anonymised/path and <torrent_name>.

I seriously have no clue what's going on.

macOS 10.15.3 Catalina
qBittorrent 4.2.1 (64-bit)

I have full ownership and security rights to both the external drives I am using, and they have exactly the same info in Disk Utility, minus the mount points and drive numbers.

Disk cache is 32MB.

One note though: for some reason the Mac's Finder shows "You have custom access" in the Sharing & Permissions section of the "Get Info" dialog. But I am presuming this is because I granted full rights to everyone using the Mac at the moment (namely chmod 0777).

@dimitarvp commented on GitHub (Feb 13, 2020): @Seeker2 here's what I am getting today again: ``` 2020 02 13 19:26 - File error alert. Torrent: "<torrent_name>". File: "/anonymised/path". Reason: <torrent_name> file_fallocate (/anonymised/path) error: Operation not supported ``` I swapped out real values with `/anonymised/path` and `<torrent_name>`. I seriously have no clue what's going on. macOS 10.15.3 Catalina qBittorrent 4.2.1 (64-bit) I have full ownership and security rights to both the external drives I am using, and they have exactly the same info in Disk Utility, minus the mount points and drive numbers. Disk cache is 32MB. One note though: for some reason the Mac's Finder shows "You have custom access" in the Sharing & Permissions section of the "Get Info" dialog. But I am presuming this is because I granted full rights to everyone using the Mac at the moment (namely `chmod 0777`).

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@dimitarvp commented on GitHub (Feb 13, 2020):

You getting lots of piece fails in qBitTorrent's logger?

No, I get one error like the one I pasted and redacted above, and then the downloading of the whole torrent stops immediately. This is about torrents with more than one file in them.

@dimitarvp commented on GitHub (Feb 13, 2020): > You getting lots of piece fails in qBitTorrent's logger? No, I get one error like the one I pasted and redacted above, and then the downloading of the whole torrent stops immediately. This is about torrents with more than one file in them.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@dimitarvp commented on GitHub (Feb 13, 2020):

Preliminary findings after relentlessly chasing this for half a day:

Seems the problem is that the external disks were formatted with exFAT. Changed one of them to HFS+ and qBittorrent had zero problems writing to it. I suspect it will also work fine with APFS but not going to try.

This reddit thread pointed me in the right direction: https://www.reddit.com/r/torrents/comments/ewjec8/operation_not_supported_creating_hard_links_on_a/

Of course, I am not sure that qBittorrent actually needs to create hard links but it doesn't matter much since changing the file system of one of my external disks immediately solved the problem.

The reddit thread also contained a link to this file systems feature matrix: https://docs.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison?redirectedfrom=MSDN

@dimitarvp commented on GitHub (Feb 13, 2020): Preliminary findings after relentlessly chasing this for half a day: Seems the problem is that the external disks were formatted with exFAT. Changed one of them to HFS+ and qBittorrent had zero problems writing to it. I suspect it will also work fine with APFS but not going to try. This reddit thread pointed me in the right direction: https://www.reddit.com/r/torrents/comments/ewjec8/operation_not_supported_creating_hard_links_on_a/ Of course, I am not sure that qBittorrent _actually_ needs to create hard links but it doesn't matter much since changing the file system of one of my external disks immediately solved the problem. The reddit thread also contained a link to this file systems feature matrix: https://docs.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison?redirectedfrom=MSDN

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@Chocobo1 commented on GitHub (Feb 13, 2020):

@dimitarvp
Your latest findings are very interesting, the file_fallocate error almost sounds like something is wrong in libtorrent. I really encourage you to bring the info over to https://github.com/arvidn/libtorrent/issues.

@Chocobo1 commented on GitHub (Feb 13, 2020): @dimitarvp Your latest findings are very interesting, the `file_fallocate` error almost sounds like something is wrong in libtorrent. I really encourage you to bring the info over to https://github.com/arvidn/libtorrent/issues.

deekerman commented

2026-02-21 20:07:13 -05:00

Author

Owner

@xavier2k6 commented on GitHub (Mar 12, 2025):

This ticket has been closed due to being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable.
If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.
A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.
Thank you for your contribution(s).

@xavier2k6 commented on GitHub (Mar 12, 2025): * This ticket has been closed due to being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable. * If you experience the reported problem or similar in the **latest** version, please open a new issue report with the requested information in the issue template. * A new issue report with relevant updated data gathered from the **latest** version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression. Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar. Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression. * Thank you for your contribution(s).

Rows
Columns

qBittorrent 4.1.9.1 is unable to re-check and restarts partially/completed downloads if you re-add a torrent. #9328

qBittorrent version and Operating System

If on linux, libtorrent-rasterbar and Qt version

What is the problem

What is the expected behavior

Steps to reproduce

Extra info(if any)