Deselecting files for download makes unexpected folders #8700

Closed
opened 2026-02-21 19:45:50 -05:00 by deekerman · 9 comments
Owner

Originally created by @speedstyle on GitHub (May 18, 2019).

qBittorrent version and Operating System

qBittorrent v4.1.5 on Lubuntu 19.04 with libtorrent v1.1.11.0 and Qt v5.11.2

What is the problem

If a text file is deselected for download before it is created, a containing folder is created.

What is the expected behavior

No changes other than deselection

Steps to reproduce

  1. Open a magnet link, wait for file metadata to load. Uncheck 'use a subfolder' (and 'start torrent').
  2. Uncheck a text file name.txt in the torrent so that it will not download
  3. Select another torrent, then refocus the torrent

The unchecked file now appears as name.txt\name.txt i.e. resides in a directory of the same name. Rechecking the file for download does not change this,

NB

I gave the steps which I had followed to achieve this error, you may be able to achieve it with a torrent file, or with 'subfolder' checked, etc. but this is my normal workflow.

Text files which have already been downloaded are not affected, nor could I find any non-txt files which did this.

EDIT

Any file which has not started to download is affected. (I noticed it on txt files as they are often the smallest and so download later.)

EDIT2

Reproduced in the Web UI:
the deselected item filename gets immediately renamed to filename\.unwanted\filename, and on deselection is renamed to filename\filename. Selecting and deselecting toggles between these, with no way to download the file (as per default) into the main download directory.

Originally created by @speedstyle on GitHub (May 18, 2019). ### qBittorrent version and Operating System qBittorrent v4.1.5 on Lubuntu 19.04 with libtorrent v1.1.11.0 and Qt v5.11.2 ### What is the problem If a text file is deselected for download before it is created, a containing folder is created. ### What is the expected behavior No changes other than deselection ### Steps to reproduce 1. Open a magnet link, wait for file metadata to load. Uncheck 'use a subfolder' (and 'start torrent'). 2. Uncheck a text file `name.txt` in the torrent so that it will not download 3. Select another torrent, then refocus the torrent The unchecked file now appears as `name.txt\name.txt` i.e. resides in a directory of the same name. Rechecking the file for download does not change this, #### NB I gave the steps which I had followed to achieve this error, you may be able to achieve it with a torrent file, or with 'subfolder' checked, etc. but this is my normal workflow. Text files which have already been downloaded are not affected, nor could I find any non-txt files which did this. #### EDIT Any file which has not started to download is affected. (I noticed it on txt files as they are often the smallest and so download later.) #### EDIT2 Reproduced in the Web UI: the deselected item `filename` gets immediately renamed to `filename\.unwanted\filename`, and on deselection is renamed to `filename\filename`. Selecting and deselecting toggles between these, with no way to download the file (as per default) into the main download directory.
Author
Owner

@a-raccoon commented on GitHub (May 18, 2019):

By default, every new torrent is placed into a subfolder of your main download directory.

When you deselect files, they are placed into the .\unwanted folder as a form of tracking which files you have deselected. This is not stored in your system registry, nor an ini file, nor an xml file. It's a .unwanted folder instead.

C:\MyDownloads\Torrent Name\.unwanted\Unwanted File

@a-raccoon commented on GitHub (May 18, 2019): By default, every new torrent is placed into a subfolder of your main download directory. When you deselect files, they are placed into the .\unwanted folder as a form of tracking which files you have deselected. This is not stored in your system registry, nor an ini file, nor an xml file. It's a .unwanted folder instead. C:\MyDownloads\Torrent Name\\\.unwanted\Unwanted File
Author
Owner

@speedstyle commented on GitHub (May 19, 2019):

Re-read my initial bug report.

By default, every new torrent is placed into a subfolder of your main download directory.

A default option which I uncheck on adding torrents.

When you deselect files, they are placed into the .unwanted folder as a form of tracking which files you have deselected. This is not stored in your system registry, nor an ini file, nor an xml file. It's a .unwanted folder instead.

The .unwanted folder is a deprecated (#2659) place to store files which we don't want to download, but need to partially or fully download as they share pieces with downloaded files. This is not a form of tracking - which is stored with the rest of the torrent metadata in ~\.local\share\data\qBittorrent\BT_backup\<hash>.fastresume.

C:\MyDownloads\Torrent Name\.unwanted\Unwanted File

See the subfolder comment above; also, I don't have a C drive as I am running Lubuntu Disco as per my initial bug report.

@speedstyle commented on GitHub (May 19, 2019): Re-read my initial bug report. > By default, every new torrent is placed into a subfolder of your main download directory. A default option which I uncheck on adding torrents. > When you deselect files, they are placed into the `.unwanted` folder as a form of tracking which files you have deselected. This is not stored in your system registry, nor an ini file, nor an xml file. It's a .unwanted folder instead. The `.unwanted` folder is a deprecated (#2659) place to store files which we don't want to download, but need to partially or fully download as they share pieces with downloaded files. This is not a form of tracking - which is stored with the rest of the torrent metadata in `~\.local\share\data\qBittorrent\BT_backup\<hash>.fastresume`. > `C:\MyDownloads\Torrent Name\.unwanted\Unwanted File` See the subfolder comment above; also, I don't have a C drive as I am running Lubuntu Disco as per my initial bug report.
Author
Owner

@speedstyle commented on GitHub (May 19, 2019):

My guess is that this is a bug relating to the implementation of #2659: previously, if a subfolder wasn't used for each torrent, unwanted files would need a folder to go into (so that the .unwanted folder wasn't shared between lots of torrents). Now that <hash>.parts files are used instead, this shouldn't be necessary, but the folders are still created.

@speedstyle commented on GitHub (May 19, 2019): My guess is that this is a bug relating to the implementation of #2659: previously, if a subfolder wasn't used for each torrent, unwanted files would need a folder to go into (so that the `.unwanted` folder wasn't shared between lots of torrents). Now that `<hash>.parts` files are used instead, this shouldn't be necessary, but the folders are still created.
Author
Owner

@thalieht commented on GitHub (May 19, 2019):

Duplicate of #9242

/offtopic
.unwanted is the folder that unwanted files go when they are unchecked after they have been partially/completely downloaded. The .unwanted folder is completely a qBittorrent thing while .parts file is handled by libtorrent. Don't quote me on this because i'm not very familiar with libtorrent but i don't think it's possible to add pieces to the .parts file after the torrent has been added to the session. If it was, .unwanted would truly be redundant.

@thalieht commented on GitHub (May 19, 2019): Duplicate of #9242 /offtopic .unwanted is the folder that unwanted files go when they are unchecked _after_ they have been partially/completely downloaded. The .unwanted folder is completely a qBittorrent thing while .parts file is handled by libtorrent. Don't quote me on this because i'm not very familiar with libtorrent but i don't think it's possible to add pieces to the .parts file after the torrent has been added to the session. If it was, .unwanted would truly be redundant.
Author
Owner

@speedstyle commented on GitHub (May 19, 2019):

OK, I'll watch its progress there.

/offtopic

I didn't realize that: does that mean I can avoid these folders by unchecking files in the torrent add window rather than later? What if I select something previously unselected for download - does it get pulled out the .parts file? Also, all of the torrents I've been testing this on have just one or two pieces downloaded: why are the .unwanted folders still created?

@speedstyle commented on GitHub (May 19, 2019): OK, I'll watch its progress there. > /offtopic I didn't realize that: does that mean I can avoid these folders by unchecking files in the torrent add window rather than later? What if I select something previously unselected for download - does it get pulled out the `.parts` file? Also, all of the torrents I've been testing this on have just one or two pieces downloaded: why are the `.unwanted` folders still created?
Author
Owner

@thalieht commented on GitHub (May 19, 2019):

does that mean I can avoid these folders by unchecking files in the torrent add window rather than later?

In your case no because as stated in the other issue it's a bug when not using "Create subfolder" but with that option yes.

What if I select something previously unselected for download - does it get pulled out the .parts file?

Yes.

Also, all of the torrents I've been testing this on have just one or two pieces downloaded: why are the .unwanted folders still created?

Not sure what you mean but in general, AFAIK, the .unwanted code hasn't been touched in years so old issues are still present with it. I think that's mainly because at some point the devs wanted to remove the .unwanted folder functionality.

@thalieht commented on GitHub (May 19, 2019): >does that mean I can avoid these folders by unchecking files in the torrent add window rather than later? In your case no because as stated in the other issue it's a bug when not using "Create subfolder" but with that option yes. >What if I select something previously unselected for download - does it get pulled out the .parts file? Yes. >Also, all of the torrents I've been testing this on have just one or two pieces downloaded: why are the .unwanted folders still created? Not sure what you mean but in general, AFAIK, the .unwanted code hasn't been touched in years so old issues are still present with it. I think that's mainly because at some point the devs wanted to remove the .unwanted folder functionality.
Author
Owner

@speedstyle commented on GitHub (May 19, 2019):

In your case no because as stated in the other issue it's a bug when not using "Create subfolder" but with that option yes.

Both this and the other issue refer specifically to selecting or deselecting things after they are added to the session, so I just meant I should be able to workaround the issue (while it is still a bug) by deciding which things to download before adding them, and re-adding them where I need to change something.

Also, all of the torrents I've been testing this on have just one or two pieces downloaded: why are the .unwanted folders still created?

Not sure what you mean but in general, AFAIK, the .unwanted code hasn't been touched in years so old issues are still present with it. I think that's mainly because at some point the devs wanted to remove the .unwanted folder functionality.

I meant that the text file hadn't actually been downloaded yet: the torrent had barely started. I was wondering why setting them not to download - when they hadn't yet been downloaded - would create the folders (could it be to do with 'pre-allocate disk space' being checked?).

@speedstyle commented on GitHub (May 19, 2019): > In your case no because as stated in the other issue it's a bug when not using "Create subfolder" but with that option yes. Both this and the other issue refer specifically to selecting or deselecting things after they are added to the session, so I just meant I should be able to workaround the issue (while it is still a bug) by deciding which things to download before adding them, and re-adding them where I need to change something. > > Also, all of the torrents I've been testing this on have just one or two pieces downloaded: why are the .unwanted folders still created? > > Not sure what you mean but in general, AFAIK, the .unwanted code hasn't been touched in years so old issues are still present with it. I think that's mainly because at some point the devs wanted to remove the .unwanted folder functionality. I meant that the text file hadn't actually been downloaded yet: the torrent had barely started. I was wondering why setting them not to download - when they hadn't yet been downloaded - would create the folders (could it be to do with 'pre-allocate disk space' being checked?).
Author
Owner

@a-raccoon commented on GitHub (May 19, 2019):

I'm not sure if this has been fully touched on, or if it answers your question, but even though you deselected a small text file, qBittorrent still NEEDS to download that small text file if it shares a part-chunk of your wanted file(s).

Example: Your text file is only 100 KB. The torrent is chunked into 80 MB parts. Your unwanted text file is part of an 80 MB chunk that belongs to the linux distro ISO that you are attempting to download, and so the unwanted text file still needs to be downloaded so a hash check calculation can be performed on the whole 80 MB chunk to validate the download was successful.

@a-raccoon commented on GitHub (May 19, 2019): I'm not sure if this has been fully touched on, or if it answers your question, but even though you deselected a small text file, qBittorrent still NEEDS to download that small text file if it shares a part-chunk of your wanted file(s). Example: Your text file is only 100 KB. The torrent is chunked into 80 MB parts. Your unwanted text file is part of an 80 MB chunk that belongs to the linux distro ISO that you are attempting to download, and so the unwanted text file still needs to be downloaded so a hash check calculation can be performed on the whole 80 MB chunk to validate the download was successful.
Author
Owner

@thalieht commented on GitHub (May 19, 2019):

when they hadn't yet been downloaded - would create the folders (could it be to do with 'pre-allocate disk space' being checked?).

Creating empty folders was fixed some time ago so this is probably part of the problem with not using subfolder but unless it is tested, i wouldn't rule out some missed edge case like the one you mentioned.

@thalieht commented on GitHub (May 19, 2019): >when they hadn't yet been downloaded - would create the folders (could it be to do with 'pre-allocate disk space' being checked?). Creating empty folders was fixed some time ago so this is probably part of the problem with not using subfolder but unless it is tested, i wouldn't rule out some missed edge case like the one you mentioned.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/qBittorrent#8700
No description provided.