starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Lost destination of completed files #3633

New issue

Closed

opened 2026-02-21 16:52:48 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-21 16:52:48 -05:00

Owner

Originally created by @CorruptedMinds on GitHub (Dec 26, 2015).

Qbittorrent 3.3.1
Computer crashed. Windows 10 64 bit.

After crash, all previously finished and seeding files are in 'paused state'.
The directory they had been in is reset to installation directory of qbittorrent
(C:\Program Files (x86)\qBittorrent)

The files themselves were (and are) on network storage, the completed torrent files are stored on a usb drive.
I can manually 'set location' in qbitorrent to the location the files are in, and it will successfully recheck/resume the files.

I don't really want to do this for the 1000 files i am(was) seeding.

Originally created by @CorruptedMinds on GitHub (Dec 26, 2015). Qbittorrent 3.3.1 Computer crashed. Windows 10 64 bit. After crash, all previously finished and seeding files are in 'paused state'. The directory they had been in is reset to installation directory of qbittorrent (C:\Program Files (x86)\qBittorrent) The files themselves were (and are) on network storage, the completed torrent files are stored on a usb drive. I can manually 'set location' in qbitorrent to the location the files are in, and it will successfully recheck/resume the files. I don't really want to do this for the 1000 files i am(was) seeding.

deekerman closed this issue

2026-02-21 16:52:53 -05:00

deekerman commented

2026-02-21 16:52:54 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Dec 27, 2015):

Soft dependency for v3.3.2. @glassez you might want to look into this. When the path is C:\Program Files (x86)\qBittorrent that the path passed to libtorrent is an empty string. We should let this happen.
(empty string means use the current working dir)

@sledgehammer999 commented on GitHub (Dec 27, 2015): Soft dependency for v3.3.2. @glassez you might want to look into this. When the path is `C:\Program Files (x86)\qBittorrent` that the path passed to libtorrent is an empty string. We should let this happen. (empty string means use the current working dir)

deekerman commented

2026-02-21 16:52:54 -05:00

Author

Owner

@moejoemoe commented on GitHub (Dec 31, 2015):

Same here. Really annoying. :/

@moejoemoe commented on GitHub (Dec 31, 2015): Same here. Really annoying. :/

deekerman commented

2026-02-21 16:52:54 -05:00

Author

Owner

@coolio2013 commented on GitHub (Dec 31, 2015):

Same here, 100% and also partly completed torrents affected. Furthermore:

-Save path is correct, payload IS existing. Setting that very same path again would not recheck torrent (which I know qbt would do in previous versions). Instead, 'Downloading meta data' is eventually displayed - which is totall wrong, because I DO have that {hash}.torrent in \BT_backup, with timestamp when it was downloaded.
-progress is 0%, 'Date added' is today, after upgrading from 3.3.0 to 3.3.1 today.
-'Force recheck' is not in context any more for that torrent, but available for other torrents, which were paused for several weeks now.
-Torrents with 100%, which were paused earlier as well, are now 0% (date added: today) and 'queued'. 1 incomplete torrent is 'Paused'. 'Completed on', 'Pieces', 'Created on' etc. is empty in tab 'General'.
-There is not any content displayed in torrents affected! Probably the reason why 'Force recheck' is missing.

This is the entry for a 100% torrent (now displayed 0% and 'queued', no content shown in tab 'General'):
LOG: 31.12.2015 12:54:47 - '.... [FLAC 24-192]' resumed. (fast resume)

Again, I can not check the entire log, because earliest entries are lost. I would AGAIN recommend to write into a LOG file (optional).
BTW, lines of the LOG can be selected with CTRL-A, but they won't become unselected (I would expect 1 line is selected after click on a line).

I did not notice this with 3.3.0, and changelog of 3.3.1 does not mention anything related?
This reminds me on my report #3602. Was it messed up? It would mean that already downloaded pieces might be overwritten with 0!

XP-32-SP3.

@coolio2013 commented on GitHub (Dec 31, 2015): Same here, 100% and also partly completed torrents affected. Furthermore: -Save path is correct, payload _IS_ existing. Setting that very same path again would not recheck torrent (which I know qbt would do in previous versions). Instead, 'Downloading meta data' is eventually displayed - which is totall wrong, because I _DO_ have that {hash}.torrent in \BT_backup, with timestamp when it was downloaded. -progress is 0%, 'Date added' is today, after upgrading from 3.3.0 to 3.3.1 today. -'Force recheck' is not in context any more for that torrent, but available for other torrents, which were paused for several weeks now. -Torrents with 100%, which were paused earlier as well, are now 0% (date added: today) and 'queued'. 1 incomplete torrent is 'Paused'. 'Completed on', 'Pieces', 'Created on' etc. is empty in tab 'General'. -There is not any content displayed in torrents affected! Probably the reason why 'Force recheck' is missing. This is the entry for a 100% torrent (now displayed 0% and 'queued', no content shown in tab 'General'): LOG: 31.12.2015 12:54:47 - '.... [FLAC 24-192]' resumed. (fast resume) Again, I can not check the entire log, because earliest entries are lost. I would AGAIN recommend to write into a LOG file (optional). BTW, lines of the LOG can be selected with CTRL-A, but they won't become unselected (I would expect 1 line is selected after click on a line). I did not notice this with 3.3.0, and changelog of 3.3.1 does not mention anything related? This reminds me on my report #3602. Was it messed up? It would mean that already downloaded pieces might be overwritten with 0! XP-32-SP3.

deekerman commented

2026-02-21 16:52:55 -05:00

Author

Owner

@glassez commented on GitHub (Jan 1, 2016):

@CorruptedMinds, @moejoemoe, @coolio2013, can you provide me .fastresume files for affected torrents? (Preferably, if you didn't do anything with these torrents after.)

@glassez commented on GitHub (Jan 1, 2016): @CorruptedMinds, @moejoemoe, @coolio2013, can you provide me .fastresume files for affected torrents? (Preferably, if you didn't do anything with these torrents after.)

deekerman commented

2026-02-21 16:52:55 -05:00

Author

Owner

@coolio2013 commented on GitHub (Jan 1, 2016):

Here you are. There doesn't seem to be a possibility to send a PM on github. And I can't reply by email, as my email service does not accept the email for replying...

HTH.

Happy New Year...
coolio2013

f039a847bbd84739e88e91407c059ff5f248633a.fastresume.zip
f339c917cf06c67010b359b2edde27d214d1ce99.fastresume.zip

@coolio2013 commented on GitHub (Jan 1, 2016): Here you are. There doesn't seem to be a possibility to send a PM on github. And I can't reply by email, as my email service does not accept the email for replying... HTH. Happy New Year... coolio2013 [f039a847bbd84739e88e91407c059ff5f248633a.fastresume.zip](https://github.com/qbittorrent/qBittorrent/files/75926/f039a847bbd84739e88e91407c059ff5f248633a.fastresume.zip) [f339c917cf06c67010b359b2edde27d214d1ce99.fastresume.zip](https://github.com/qbittorrent/qBittorrent/files/75927/f339c917cf06c67010b359b2edde27d214d1ce99.fastresume.zip)

deekerman commented

2026-02-21 16:52:55 -05:00

Author

Owner

@glassez commented on GitHub (Jan 1, 2016):

@coolio2013, apparently, you didn't understand what I need, since you sent me workable files...

@glassez commented on GitHub (Jan 1, 2016): @coolio2013, apparently, you didn't understand what I need, since you sent me workable files...

deekerman commented

2026-02-21 16:52:55 -05:00

Author

Owner

@coolio2013 commented on GitHub (Jan 1, 2016):

Uh? Sorry, but what else did you expect?
-No content is shown in qbt, although files are 100%, and where they should be, 'Force recheck' not available in context menu here
-progess shown in qbt is 0%

Nothing is wrong with these 2 files then? I don't get it.

@coolio2013 commented on GitHub (Jan 1, 2016): Uh? Sorry, but what else did you expect? -No content is shown in qbt, although files are 100%, and where they should be, 'Force recheck' not available in context menu here -progess shown in qbt is 0% Nothing is wrong with these 2 files then? I don't get it.

deekerman commented

2026-02-21 16:52:55 -05:00

Author

Owner

@CorruptedMinds commented on GitHub (Jan 1, 2016):

I tried to fix all of mine, but i believe this one could be one with the issue...
Also note that I had over 1000 torrents added, after the crash, there were only 300 or so.. And all of them errored

f7d711f61c57bab9269eaf07acd24833a0ca0814.fastresume.zip
screenshots.zip

@CorruptedMinds commented on GitHub (Jan 1, 2016): I tried to fix all of mine, but i _believe_ this one could be one with the issue... Also note that I had over 1000 torrents added, after the crash, there were only 300 or so.. And all of them errored [f7d711f61c57bab9269eaf07acd24833a0ca0814.fastresume.zip](https://github.com/qbittorrent/qBittorrent/files/75955/f7d711f61c57bab9269eaf07acd24833a0ca0814.fastresume.zip) [screenshots.zip](https://github.com/qbittorrent/qBittorrent/files/75957/screenshots.zip)

deekerman commented

2026-02-21 16:52:55 -05:00

Author

Owner

@glassez commented on GitHub (Jan 3, 2016):

@sledgehammer999, here are some of my conclusions.
This problem is quite serious and it requires an integrated approach to their solution. The most critical data for torrent resuming is save path and file names (if user changed it). If in the event of a system failure we lose this data, then, by and large, we remain without hands (we can no longer recover the torrent). Nicely, we should simply report the error and provide the user fix it manually. I found a bug in the code that allows you to upload the corrupted .fastresume file, thereby exacerbating the problem (fixed in first commit of #4482). Another catalyst of the problem is the slow fastresume data processing (saving) algorithm, implemented in the current versions. This increases the chances of data loss when the system crashes. Fixed in #4403.
So the current (still not merged) patches should significantly reduce the possibility of this problem, and in the future we need to seriously address the issue of preserving critical data in the event of a system failure.

@glassez commented on GitHub (Jan 3, 2016): @sledgehammer999, here are some of my conclusions. This problem is quite serious and it requires an integrated approach to their solution. The most critical data for torrent resuming is **save path** and **file names** (if user changed it). If in the event of a system failure we lose this data, then, by and large, we remain without hands (we can no longer recover the torrent). Nicely, we should simply report the error and provide the user fix it manually. I found a bug in the code that allows you to upload the corrupted .fastresume file, thereby exacerbating the problem (fixed in first commit of #4482). Another catalyst of the problem is the slow fastresume data processing (saving) algorithm, implemented in the current versions. This increases the chances of data loss when the system crashes. Fixed in #4403. So the current (still not merged) patches should significantly reduce the possibility of this problem, and in the future we need to seriously address the issue of preserving critical data in the event of a system failure.

deekerman commented

2026-02-21 16:52:55 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Mar 17, 2016):

Both patches are merged now. They'll be included in the soon to be released v3.3.4.

@sledgehammer999 commented on GitHub (Mar 17, 2016): Both patches are merged now. They'll be included in the soon to be released v3.3.4.