qBittorrent official forums

Scenario:
1 large torrent (TV Season) containing many files (episodes).
I choose to download only one file.
I also will eventually delete that one file, so I have storage to download the next file.

For this example, there are 3 files (A, B, C).

I don't completely understand the .unwanted folder, but I think I understand the contents of what appears to be individual files also contains chunks of content in  what appears to be other files.

I decide to download file B.  Some of file B's contents are in file A and file C.  What qBittorrent does is creates files A and C in the unwanted folder.  These are full size files, and don't appear to be partials.

Something else I noticed that I haven't had time to full test.  I finish watching file B and want to delete it, but I also need to find file A and delete it too (potential problem?).  I then select file C from the UI to begin download.  But I also have file C in the unwanted folder.  I have some doubts qBittorrent is handling this correctly because I have found duplicate files in both folders (file C will exists twice).

It seems uTorrents behavior is different.  The partial files (blocks) are stored in a single separate file.  The advantage is no wasted storage.

Thanks,
Jake

They are called "cross-file pieces" and there are several threads on the topic of the '.unwanted' folder, explaining the whys and wherefores.

From FAQ:

I configured qBittorrent to not download some files in a torrent but they still appear on my hard disk, why is that?

As you may know, a torrent is split into pieces of equal size that do not take files into consideration. As a consequence, a piece can contain information relative to more than one file and qBittorrent only operates at piece level. Because of this, if two files are adjacent and you choose to download only one of them, it is likely that the filtered one will be partially downloaded and thus appear on the hard-disk.

As ciao said already; there are several threads about this already at this forum and Github page. Like for example: https://github.com/qbittorrent/qBittorrent/issues/109.

Things might change in the upcoming releases but don't get my word for it.

What I don't understand is why QB stores the entire cross file, not just the pieces, which consumes unnecessary storage space.
uTorrent (presuming) keeps these pieces in a separate and smaller file; the only storage being consumed are the cross file pieces.

Additionally, I'm wondering if I found a problem when I decide later I want to download an "unwanted" file.  What happens to the "unwanted" file in the "unwanted" folder?  I want to make sure it doesn't get duplicated in both places.  I found in a few of my cases I had duplicates (a file in both the unwanted and the parent folder).

What I don't understand is why QB stores the entire cross file,

It is your operating system disc filing system that 'decides' how to allocate the space.

Do you have preallocate enabled?

if you righ click->properties you should see that the "size on disk" is minimal.
Unless either you have preallocation enabled or the files were moved/copied from another disk/partition.

Yes, I have preallocate enabled; with the presumption this would reduce disk wear and fragmentation.

I have the same question SineSwiper does:

Why not store the partial chunks into a single file on the root directory, which is how uTorrent handles it?

Then pre-allocate WILL allocate AND USE  all the space required by the WHOLE payload.

Why not store the partial chunks into a single file

That will make ZERO difference if you are preallocating the payload.

If I don't select the individual file (on a multi-file torrent), then the application shouldn't be allocating 100% storage to it.  The application should only download/store the necessary cross bits.
Ideally those cross bits won't be stored in the same file that hasn't been selected; this creates too much confusion and is not as elegant as other solutions.

If I don't select the individual file (on a multi-file torrent), then the application shouldn't be allocating 100% storage to it.  The application should only download/store the necessary cross bits.

http://www.libtorrent.org/manual-ref.ht ... allocation

"The traditional full allocation mode, where the entire files [not the torrent] are filled up with zeros before anything is downloaded."

I don't expect the deselected file to be fully allocated.
From what I'm understanding is there are still some required bit parts that are organized into the deselected files.

I'd be happy with:
a)  The bit/parts that span into deselected files are allocated into a separate file.  Perhaps named partsfile.dat.
or
b)  The deselected files be sparse.

partfile.dat support is implemented in libtorrent trunk: https://code.google.com/p/libtorrent/is ... ail?id=395
For those you don't know: libtorrent trunk is the next major and stable version of libtorrent. Currently it is considered unstable and doesn't have any release.