starred/qBittorrent

Fork 0

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

Monster sized parts file, as large as the total torrent content #6724

New issue

Closed

opened 2026-02-21 18:34:44 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-21 18:34:44 -05:00

Owner

Originally created by @mzso on GitHub (Jan 6, 2018).

qBittorrent version and Operating System

4.0.3

What is the problem

I was wondering where is all the space going. Then I realized parts files were created that are ridiculously huge even though all the space was already allocated to the files.

It seems like yet another bug related to checking files that were previously unselected. Because I did exactly that. I also moved some unfinished torrents between drives because I kept running out of space not knowing why.

What is the expected behavior

Not wasting space pointlessly

Two of these are not like the others:

Originally created by @mzso on GitHub (Jan 6, 2018). ### qBittorrent version and Operating System 4.0.3 ### What is the problem I was wondering where is all the space going. Then I realized parts files were created that are ridiculously huge even though all the space was already allocated to the files. It seems like yet another bug related to checking files that were previously unselected. Because I did exactly that. I also moved some unfinished torrents between drives because I kept running out of space not knowing why. ### What is the expected behavior Not wasting space pointlessly Two of these are not like the others: ![giant-part-file2](https://user-images.githubusercontent.com/4479090/34665106-4e59c546-f45f-11e7-9c78-75c428fa2bc8.png)

deekerman

2026-02-21 18:34:44 -05:00

closed this issue
added the
Libtorrent
label

deekerman commented

2026-02-21 18:34:48 -05:00

Author

Owner

@mzso commented on GitHub (Jan 6, 2018):

#8070 also came up again for several files, downloading just stops before files are finished. Example:

@mzso commented on GitHub (Jan 6, 2018): #8070 also came up again for several files, downloading just stops before files are finished. Example: ![kep](https://user-images.githubusercontent.com/4479090/34638919-ff83bdb2-f2d5-11e7-8d70-38b27d6d1680.png)

deekerman commented

2026-02-21 18:34:50 -05:00

Author

Owner

@thalieht commented on GitHub (Jan 6, 2018):

Check the piece size for each torrent. Combine that with the logical assumption that you deselect several files in these torrents, whose pieces are not adjacent to each other, ergo must download more cross-file pieces.
This info is in the General tab.

EDIT: Never mind i just saw the giga size files. Something must indeed be wrong.

@thalieht commented on GitHub (Jan 6, 2018): Check the piece size for each torrent. Combine that with the logical assumption that you deselect several files in these torrents, whose pieces are not adjacent to each other, ergo must download more cross-file pieces. This info is in the General tab. EDIT: Never mind i just saw the giga size files. Something must indeed be wrong.

deekerman commented

2026-02-21 18:34:50 -05:00

Author

Owner

@mzso commented on GitHub (Apr 1, 2018):

@arvidn
Hi!
Do you think it might be a libtorrent issue. Not sure if QB can even touch anything partfile related, if I'm not mistaken low level stuff like this is mostly libtorrent's realm.
There are other rather serious issues that popped up related to files (being moved (de)selected): #7966, #8070

@mzso commented on GitHub (Apr 1, 2018): @arvidn Hi! Do you think it might be a libtorrent issue. Not sure if QB can even touch anything partfile related, if I'm not mistaken low level stuff like this is mostly libtorrent's realm. There are other rather serious issues that popped up related to files (being moved (de)selected): #7966, #8070

deekerman commented

2026-02-21 18:34:50 -05:00

Author

Owner

@arvidn commented on GitHub (Apr 1, 2018):

Those large partfiles, are they larger than the total size of the torrent?
Do they approximately represent the size of the files that were de-selected?
The file format is pretty simple, the first two fields (4 bytes each) is the total number of pieces and the piece size of the torrent. This is followed by an array of num-pieces slots (also 4 bytes), each indicating which piece is stored in the respective slot. 0xffffffff indicates the slot is empty (and shouldn't be allocated on disk).

So, for the large part files, I wonder if some file keeps getting downloaded into the partfile even though it should have priority zero. @mzso any chance you could hexdump -C the first few hundred bytes of one of the files?

@arvidn commented on GitHub (Apr 1, 2018): Those large partfiles, are they larger than the total size of the torrent? Do they approximately represent the size of the files that were de-selected? The file format is pretty simple, the first two fields (4 bytes each) is the total number of pieces and the piece size of the torrent. This is followed by an array of num-pieces slots (also 4 bytes), each indicating which piece is stored in the respective slot. 0xffffffff indicates the slot is empty (and shouldn't be allocated on disk). So, for the large part files, I wonder if some file keeps getting downloaded into the partfile even though it should have priority zero. @mzso any chance you could ``hexdump -C`` the first few hundred bytes of one of the files?

deekerman commented

2026-02-21 18:34:50 -05:00

Author

Owner

@mzso commented on GitHub (Apr 1, 2018):

@arvidn commented on 2018. ápr. 1. 23:42 CEST:

Those large partfiles, are they larger than the total size of the torrent?

No they weren't

Do they approximately represent the size of the files that were de-selected?

I googled the hashcodes and they both seems to have been somewhat smaller. The size for both is 12.87GB.

So, for the large part files, I wonder if some file keeps getting downloaded into the partfile even though it should have priority zero. @mzso any chance you could hexdump -C the first few hundred bytes of one of the files?

I don't have them anymore. I should have thought about notifying you when I encountered this, but it didn't occur to me at the time.

All I can say right now that only started with some files from both torrents then I started runinng out of space (some torrents might have stopped downloading because of this, though not changing to an errored state, of which I'm sure of). So I set some of their location to a different drive, including these two I think, but the space wasn't getting freed up that's when I noticed this huge part files. (Part files are not moved from the initial location with the content files)
Maybe if I'll have lots of time sometime I'll try to recreate this but I don't think it'd be an easy task with files being checked progressively, disk space running out and moving between drives. (In who knows what order)

On a side note:
Is the .unwanted folder still appearing (#7966) a normal thing with the 4.0 QB line (and the libtorrent version it uses). It can be quite bothersome and eclectic with several empty folders with also empty .unwanted folders in them.

@mzso commented on GitHub (Apr 1, 2018): [**@arvidn**](https://github.com/arvidn) commented on [2018. ápr. 1. 23:42 CEST](https://github.com/qbittorrent/qBittorrent/issues/8225#issuecomment-377818965 "2018-04-01T21:42:29Z - Replied by Github Reply Comments"): > Those large partfiles, are they larger than the total size of the torrent? No they weren't > Do they approximately represent the size of the files that were de-selected? > I googled the hashcodes and they both seems to have been somewhat smaller. The size for both is 12.87GB. > > So, for the large part files, I wonder if some file keeps getting downloaded into the partfile even though it should have priority zero. [@mzso](https://github.com/mzso) any chance you could `hexdump -C` the first few hundred bytes of one of the files? I don't have them anymore. I should have thought about notifying you when I encountered this, but it didn't occur to me at the time. All I can say right now that only started with some files from both torrents then I started runinng out of space (some torrents might have stopped downloading because of this, though not changing to an errored state, of which I'm sure of). So I set some of their location to a different drive, including these two I think, but the space wasn't getting freed up that's when I noticed this huge part files. (Part files are not moved from the initial location with the content files) Maybe if I'll have lots of time sometime I'll try to recreate this but I don't think it'd be an easy task with files being checked progressively, disk space running out and moving between drives. (In who knows what order) On a side note: Is the .unwanted folder still appearing (#7966) a normal thing with the 4.0 QB line (and the libtorrent version it uses). It can be quite bothersome and eclectic with several empty folders with also empty .unwanted folders in them.

deekerman commented

2026-02-21 18:34:50 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Sep 14, 2020):

@mzso can you reproduce this in a recent master build with libtorrent >= 1.2.10? The .unwanted folder feature has been removed since this was originally posted...

If you need Windows builds, use one of these: https://github.com/FranciscoPombal/qBittorrent/actions (version: 1c87073990 + libtorrent >= 1.2.10)

@FranciscoPombal commented on GitHub (Sep 14, 2020): @mzso can you reproduce this in a recent `master` build with libtorrent >= 1.2.10? The `.unwanted` folder feature has been removed since this was originally posted... If you need Windows builds, use one of these: https://github.com/FranciscoPombal/qBittorrent/actions (version: 1c8707399090666efdf017f2ece87a5c53088669 + libtorrent >= 1.2.10)

deekerman commented

2026-02-21 18:34:50 -05:00

Author

Owner

@mzso commented on GitHub (Sep 15, 2020):

Well, I couldn't really recreate it even then. I haven't noticed it happening again.

@mzso commented on GitHub (Sep 15, 2020): Well, I couldn't really recreate it even then. I haven't noticed it happening again.

deekerman commented

2026-02-21 18:34:50 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Sep 15, 2020):