Qbittorrent: I know .unwanted folder was meant to be gone, but what's new behaviour supposed to be?

[BattouSaeen]

Please provide the following information

qBittorrent version and Operating System

4.3.0

If on linux, libtorrent-rasterbar and Qt version

(type here)

What is the problem

Not a problem per say, but the .unwanted folder being as buggy as it was, still had the utility of keeping things kinda "organised". For instance, let's say I'm comparing two different torrents with similar files, e.g. same filename but one torrent has higher quality and another has lower quality. Unchecking a file in one torrent sent it to the .unwanted folder earlier. Like a temporary holding place. If I went into both folders and compared them, I would see a file in .unwanted which meant that I had unchecked it in qB. It was a good way to reflect what was in qB without having to open and checking in qB.

So what happens now? I tested by unchecking a file and nothing happened in the folder - the file was still there even though I unchecked it in qB. While not a big issue, I did like the ability to see that correspondence between qB and folder structure by way of the organisation .unwanted offered. Or is there something that's meant to happen and it hasn't happened?

What is the expected behavior

(type here)

Steps to reproduce

(type here)

Extra info(if any)

(type here)

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ghost]

It will create .parts files. You may have to show hidden files.

[KayLeung]

It seems buggy.

The new behavior just does nothing. (by my real test and read the patch code)

Assumed you've selected all files to download at the beginning, and then uncheck a file.

new behavior:
If the file is started, remains as !qB.
If the file is finished, keep the file.

old behavior:
unchecked files are move to .unwanted

old behavior, we able to perform a quick search and clean it up the whole .unwanted folder
new behavior, you have to go into each dir to remove the unwanted files (1 more action than before. first uncheck, then go into folder to remove)

I rolled back to the old version.

(I can't find a thread to explain why to remove .unwanted btw, anyone can help?)

[FranciscoPombal]

Can confirm the following: if the files are selected when the torrent is added, and deselected afterwards, they are not removed from disk, and there is no real indication at the file system level that they have been removed from the client.

On the other hand, if they are deselected right when adding the torrent, it seems to behave correctly: the deselected files are not downloaded.

Either way, the parts file for the pieces at file boundaries get created, as expected, if needed. In the first case, since the files are kept, it is possible that no parts file is created, since the required pieces may be contained in the partially downloaded files.

I am curious as to what would be the preferred behavior, and how flexible libtorrent can be with regards to this:

• Immediately delete files when they are deselected
• Re-introduce a fixed version of the .unwanted folder
• Leave as-is
• Something else

[KayLeung]

Immediately delete files when they are deselected

It's bad for mis-clicked

Leave as-is

a lot of confusion. One of my testings, it leaves a zero bit file

What's wrong with the .unwanted folder?

[thalieht]

Essentially, unchecking already downloaded (even partially) files has no effect now.
.parts files are handled by libtorrent, while .unwanted folder was entirely a qBt "feature" but it was always buggy and it kept creating problems so... it's gone now.

[BattouSaeen]

Yeah to be honest, I never had any issues at all with the .unwanted folder. Never had any bugs or issues no matter which version I used, so I kinda loved it, offered a nice dimension to organisation, all the while connected directly to the qB interface, which acts as a great file manager on its own. I might downgrade if there are no plans to reimplement a better/fixed/evolved version of the .unwanted folder.

[FranciscoPombal]

@arvidn Do you have any suggestions about this?

[qaxifm]

.unwanted foler is why I like qbt so much, Imagine torrent with over 1000 files removing some of them them manually after unchecking when they are already downloaded is terrible task. when they are in one place it's piece of cake

[arvidn]

one problem with the .unwanted folder was that it relied on the filesystem supporting sparse files. zero-priority files still (typically) need the first and the last bit of them downloaded, assuming there are adjacent files before and after. This means that it's common for the last few kilobytes to be written to unwanted files. If your filesystem doesn't support sparse files that's expensive.

• it takes a long time to write all the zeroes do disk
• it uses a lot of disk space for no good reason (and this is a source of confusion)

The problem with the partfile on the other hand is that it's optimized for the use case of setting some files to priority 0 before starting the download, and then not changing them.

You can change your mind and "select" a file later during the download. The bits that were saved in the part file will then be copied out into the final file position, and download will resume there. At this point, if your filesystem doesn't support sparse files, it will still be expensive (just like all the other files you downloaded), but at least there's utility, you actually want this file, so paying the cost for it makes sense.

However, if you start downloading a file, and you actually receive some of its content, changing the file priority to 0 won't move it.You've already paid some of the cost of creating the file, although, it might not be fully allocated yet.

It would be possible to copy the file into the part file in this scenario, but I think it has questionable utility. It wouldn't be like moving/renaming a file. It would require reading every byte of it, and writing it into another file, in a different format, and then delete it. If it's a large file, that might be an expensive operation.

Right now, the cut-off for allowing a file into the partfile is; if it doesn't exist on disk yet, it's fine. So, at startup or close after startup, you can still set priority 0 and have it end up in the partfile.

In fact, this might make the partfile feature a perfect complement to the .unwanted folder. I think that would give you the best of both worlds.

Anyway, I'm open to suggestions for improvements.

[BattouSaeen]

@arvidn I don't really understand it, but thanks for the write up! I do see some of what you wrote in action, so I do get some of it, but nowhere near enough for a full understanding.

Is it possible to just introduce moving unchecked files into a folder similar to the .unwanted folder? i.e. if I understood what you wrote correctly, have qB keep using this new/efficient method of downloading files but upon unchecking a file, it would just move it into an "unchecked" folder but without the expensive stuff that was part of the .unwanted folder? That way we get the organisation of the .unwanted folder without the inefficiency of it. But that's assuming I got what you said.

[FranciscoPombal]

@arvidn

It would be possible to copy the file into the part file in this scenario, but I think it has questionable utility. It wouldn't be like moving/renaming a file. It would require reading every byte of it, and writing it into another file, in a different format, and then delete it. If it's a large file, that might be an expensive operation.

Please correct me if I'm wrong: the traditional .parts files are relatively small because they just have to contain data from files that were deselected at the beginning that is shared with other selected files at piece boundaries.

So, why not simply move deselected files (that were deselected after download has started) to files named .<infohash>.<filename>.parts (<filename> contains the full directory hierarchy, separated by -, for example)? This would potentially result in some duplication of some data already contained in the traditional .parts file, but I think this is an acceptable price to pay.
The data stored in the traditional .parts file probably needs to be adjusted with each of these moves for consistency, but if it is always small, it is also a small price to pay.

I imagine this would also extend well into V2. Since in V2 files are aligned at piece boundary, a simplified version of this mechanism can be used - there is no need to care about traditional .parts files, just the .<infohash>.<filename>.parts.

[arvidn]

So, why not simply move deselected files (that were deselected after download has started) to files named ...parts ( contains the full directory hierarchy, separated by -, for example)? This would potentially result in some duplication of some data already contained in the traditional .parts file, but I think this is an acceptable price to pay.

Right, or files could be moved into an .unwanted folder, it's essentially the same thing.

I don't see where there would be any duplication of data. When moving data out of the partfile, it's removed in the partfile. If there is a file on disk (today) it cannot be moved into the partfile. It will remain where it is if it's deselected.

The data stored in the traditional .parts file probably needs to be adjusted with each of these moves for consistency, but if it is always small, it is also a small price to pay.

The part file is indexed by piece and block index, so it doesn't matter what name the file it would have been stored in is called.

I imagine this would also extend well into V2. Since in V2 files are aligned at piece boundary, a simplified version of this mechanism can be used - there is no need to care about traditional .parts files, just the ...parts.

Right, the partfile would (generally) not be necessary for v2 or hybrid torrents, since files are aligned to piece boundaries.

The edge case where it might be, and where the partfile may be large is if a file is set to priority 0, but then pieces in that file are set to non-zero priority. All those pieces will end up in the part-file. I can't think of a reason a client would do that, but it's a possibility.

[github-account1111]

One way to circumvent this is to make it so unchecking a file also deletes it from disk. I've just created an issue which may be related: #13678

[BattouSaeen]

@github-account1111 that seems to be a different behaviour altogether. In this thread, we are asking for a return to the original behaviour of moving unwanted files into a separate folder (which was the .unwanted folder) as that helps in organisational tasks. I can't imagine the nightmare it would be if unchecking a file by accident means it's deleted and has to be redownloaded.

[github-account1111]

Yes, I did not think it through. However, wouldn't adding an option to delete individual files through the right-click context menu eliminate the issue?

[BattouSaeen]

I'm not sure I understand what you're trying to say, I feel like you've misunderstood this thread. In this thread we don't want the files to be deleted. We want unchecking to make the files go into a folder like the old .unwanted folder. We can easily delete them by deleting the unwanted folder ourselves in file explorer later on if need be. An option can also be added within qB to make unchecking either delete files or send them into an unwanted folder, however, what I personally request is for the unwanted folder to come back as it was a great bit of behaviour for organisation.

[github-account1111]

Your use-case for the .unwanted folder sounds like a side effect rather than the intended purpose of it. I also fail to see how the folder helped with organization. How is it different from selecting the files and comparing them from the Content tab or File Explorer? Seems like a very narrow use-case at best. My impression was that ridding of the .unwanted folder was a welcomed change by most.

[BattouSaeen]

It was the original purpose of it however it was meant to be removed, but it took a long time and most of us found it useful. You can read through this thread to see why we want it and how it helps us in organisation. It effectively helps you see a reflection of qB within file explorer. It is completely different to comparing files from content and file explorer because this latter approach requires you to have 2 apps open (explorer and qb) and you need to manually check what is unchecked/checked in qB. It's fine for a torrent with one or two files but good luck doing it with 100s. The unwanted folder acted as a kind of "purgatory" and helped us organise files within qB and if in future we ever wanted to delete the files unchecked in the future, we can go into file explorer and simply delete the unwanted folder. Or, we could go into unwanted and delete a specific file, while keeping the rest "unchecked" in their unwanted folder. It's a very powerful way to deal with some situations and I cannot imagine not having it, so I have downgraded until it hopefully gets reintroduced. As always I personally believe there should be as much choice available as possible, so ideally it would be great to have an option to use the unwanted folder behaviour for those of us who want it and for those who don't want it can disable this behaviour.

[tworepetae]

It was a very useful feature for torrents with large amounts of video/audio files which you could partially download and preview before their completion.
Here's a typical use case scenario for this feature for me:

1. Start a torrent with many videos, knowing that you will only need several of those videos. Check "download in sequential order" and "download first and last pieces first" in order for files to be previewable before their download completion.
2. The video files start being downloaded and you can start previewing them.
3. Uncheck files you don't need in the content tab after previewing them.
4. Delete the stuff in the .unwanted folder after qbt finishes downloading the remaining selected files in the torrent.
5. You're left with a clean folder of only selected and completed files.

With the new version of qbt the wanted-complete and the unwanted-incomplete files are all in the same folder, so I need to clean the incomplete ones manually. This is major inconvenience and I downgraded to 4.2.5 for this reason.
If there was an option to somehow export a list of files and their status from a particular torrent into some csv file - that would be enough to me as I would simply use it as a mask for cleanup, but right now there's nothing of the kind and a useful functionality is gone.

[morganmay]

I liked the .unwanted folder because it made cleanup of leftover files easy - just use a script to recursively find and delete directories named ".unwanted". Keeping deselected files in place with the same names makes them impossible to distinguish in a script without some external record record of their status, such as the .csv file suggested by tworepetae.