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)

[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.

[Knocks]

The .parts files should be placed either in the temp/working directory of the OS or another place, like AppData/Roaming etc. Anywhere but the downloads folder. Making these files hidden actually creates more problems than it solves.

[dennis-thomas-o]

I vote for an option in the conf file to specify a file path where we want all .parts files to be stored.

[thalieht]

I vote for an option in the conf file to specify a file path where we want all .parts files to be stored.

Irrelevant to the .unwanted folder and don't make a new issue for it. Find the existing one if you want.

[Knocks]

The title of this discussion does not reflect the current issue very well. Newcomers to qBittorrent don't even now what the .unwanted folder is, but they do see random .part files all over the place and that's what they report.

[BattouSaeen]

@Knocks I don't know what "current" issue you are referring to. This thread and its title are exactly what they are, there is no mismatch. We would like the previous behaviour where unchecking a file in qB's Content view of a torrent to send the file to an .unwanted folder. This was a very useful behaviour which allowed for ease of use and aided organisation as qB's interface acted as a file manager. With the current versions you would have to manually organise in explorer, whereas with the .unwanted folder you just uncheck whatever you don't want to send them straight into another folder. And if in future you want to delete that folder, just delete the folder. Additionally, it helps in comparing torrents that have common files (e.g. updated torrents for a single subject). You can compare files and send them into the unwanted folder as you see fit. This made the unwanted folder also act as a sort of "purgatory" where you could hold files that you would want to deal with later on. This simple "bug" feature really was a powerful feature.

[Knocks]

I am referring to the fact that several other threads seem to have been merged into this issue now. I know nothing about the unwanted folder (was not a qBittorrent user when that folder existed), but I did report that .parts files were appearing in places where they shouldn't be (as described above). Since we're not allowed to discuss that in a separate thread, we're discussing it in this hodge-podge thread.

[BattouSaeen]

@Knocks for now it seems the "solution" for both issues is to revert to 4.2.5 as I and a few others have done. You'll also get to see how this .unwanted folder behaviour works and perhaps find it useful.

[KayLeung]

Most of us keep download history. That's why .parts & .unwanted leftover.

2 basic needs here:

• unselected files should be a different name.
• A way to purge the unselected files.

I think the most simple workaround would be a "purge" (per torrent & all) command. And "auto purge" option for general users.

(So if qBitorrent provide another way to track the download history, we can remove .torrents from computers also)

[BattouSaeen]

This isn't going anywhere because things are being muddied. The original point of this thread was to have the option to have the same behaviour back. Nothing different. Any other suggestions on how to deal with folders and files should be separate feature request threads otherwise the point of this thread gets lost. This thread is about bringing back the original behaviour of the .unwanted folder keep unchecked files in it. Ideally there could be an option in the core behaviour of the programme, where a user can choose whether they want this legacy behaviour or whatever is going on currently. That way both camps are happy and the newer behaviour can go on in its progress.

[BattouSaeen]

Hello, any hope of this getting some love?

[Quantum00]

This really does need a solution. Unwanted files should easily be identified and not remain with the wanted files. The .unwanted folder made it easy to find them and easily delete them. Now it is a mess. Moving them into the partfile is not ideal in my opinion because you don't reclaim the hdd space they use. Possible solutions are to bring the .unwanted folder back or have the option to manually or automatically purge the unwanted files.

[arvidn]

keep in mind that you can't seed the torrent once you delete the partfile, so perhaps it would be a reasonable option when removing a torrent from the UI, to then remove the partfile.

[Quantum00]

keep in mind that you can't seed the torrent once you delete the partfile, so perhaps it would be a reasonable option when removing a torrent from the UI, to then remove the partfile.

And this is what is happening today and should remain as is.

The issue is unwanted (not at when the torrent was first added but after) files now remain on the hdd even after the torrent is removed from qbittorrent without them being easily identified in explorer. In the past on torrent removal from qbittorrent the .unwanted folder was deleted if i remember correctly (and even if not they were all in the .unwanted folder), thus deleting those unwanted files from the hdd.

Maybe a solution would be on unselecting an unwanted file, a per torrent context entry to purge unwanted files which would delete unchecked files from the hdd except the remnants of pieces that must be kept (usually first and/or last piece of a file contain data for previous/next files), which should be moved in the partfile. Or just delete the files from the hdd and mark those pieces for redownload if needed.

[github-account1111]

a per torrent context entry to purge unwanted files which would delete unchecked files from the hdd except the remnants of pieces that must be kept (usually first and/or last piece of a file contain data for previous/next files), which should be moved in the partfile.

This solution sounds pretty much perfect. It eliminates accidental unchecks and lets you be granular. Additionally ability to purge for selected torrents could be useful (where the .unwanted folders are deleted for selected torrents). Would take care of #13678 too I think.

[tykonin]

The whole parts thing is complete overly complicated mess. Who needs this? Why?

1) If you download many torrents (with unchecked/unwanted files) in /Downloads the directory gets full of .parts files and you don't know to which torrent these files belong. Say you download torrent in /Downloads that consists of dir A. The .parts files are not in A but one directory up (the dir in which A is, /Downloads). How is this better than .unwanted? 2) If you want to move the torrent manually, good luck picking the right .parts files. 3) If you want to migrate to different torrent client, good luck with the .parts files, especially if you are only seeder. 4) My backups become mess. Everything becomes mess. Every sane torrent client just gets the incomplete file and puts .part or smth behind the file name while the file stays in the torrent directory.

Unwanted is objectively superior solution to the bullshit we have now. Even just putting .part on unwanted(but needed) files is superior.

[Knocks]

@FranciscoPombal We had a perfectly good discussion about .parts files not belonging in the downloads folder in this thread: https://github.com/qbittorrent/qBittorrent/issues/8175

Why did you close that discussion and most importantly, why did you merge it into this, completely unrelated thread about the .unwanted folder, which I don't know or care about but get daily notifications for?

In the meantime, the main issue that people in the original thread reported is that .parts files don't belong in the downloads folder and should be in a temp folder instead.

[BattouSaeen]

As the thread starter, my (and those who agree with me - our) request is simple: 1) Keep .unwanted folder behaviour. Improve it however much if desired, but the basic behaviour is what was useful and requested; namely, unchecking a file in the qB UI should move those files to an unwanted folder and rechecking them moves them back. This allows for file management from within the UI and ties the UI and explorer shell together. For instance, searching for torrents in the UI is much faster than in Windows shell so it is easier to manage files in the UI.

2) Additionally, this behaviour allows you to deal with situations where you are not sure if some file is required or not later on. E.g.: There are two torrents (A and B) for the same collection (let's say tutorial videos). But you notice that A has a bigger size than B, even though they have identical file listings. So you download both and realise that some files in A are bigger because they are higher quality than the same named files in B. So you uncheck the same-named files in B to get the higher quality ones in B, therefore those unwanted files are moved to the unwanted folder. Here's how it gets more complicated: Having completed downloads, you notice that A's files, while bigger in size, are actually worse in quality because whoever encoded them, used a bad encoder to make them bigger in size but the quality is worse. You compare them to the unwanted file in B and see this is true. So now you can just checkmark the file in B, in qB's UI and you have the file you want and can resume its download instead of having to redownload the entiere thing. For files confirmed not-needing, you can just go to that torrent's unwanted folder and delete them because they are nicely placed in this folder instead of having to search back and forth to see what is to be deleted. This is the most powerful use of the unwanted folder.

I hope the unwanted folder comes back, in whatever form, so long as it fulfils the usecases it fulfils currently and as outlined in this post.

[Knocks]

As someone who is not the thread starter but who participated in another thread that people also cared about, my request is also simple:

1. Admins should not merge threads that are only tangentially related to avoid the clusterfuck that this discussion has become.

[ExceptionGit]

I vote for https://github.com/qbittorrent/qBittorrent/issues/13678#issuecomment-719976973 , now the "unchecking" behavior is unusable and creates a lot of empty/ghost files.

[mzso]

@arvidn commented on 2020. okt. 22. 10:26 CEST:

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.

What prevents just splicing the existing files to the partfile, without actually copying any file data?

[arvidn]

What prevents just splicing the existing files to the partfile, without actually copying any file data?

Filesystem and kernel support for doing that. Recent linux kernels and ext4 supports copy-on-write of extents of files. But as far as I know, MacOS/APFS only supports that for whole files, not at the extents level, and I'm not aware of any support for that on windows. Do you have any suggestions?

[mzso]

@arvidn commented on 2021. szept. 12. 00:30 CEST:

What prevents just splicing the existing files to the partfile, without actually copying any file data?

Filesystem and kernel support for doing that. Recent linux kernels and ext4 supports copy-on-write of extents of files. But as far as I know, MacOS/APFS only supports that for whole files, not at the extents level, and I'm not aware of any support for that on windows.

Ah, thanks for the explanation

Do you have any suggestions?

I wish. I was just curious about what the technical reason was.

[KayLeung]

It wouldn't be like moving/renaming a file.

From my understanding, this has no drawbacks?

Are we talking about extra clean-up of the data from partfile?

(Can't we bring back distinguishable filenames first?)

If I perform the following actions, what bugs I will face?

• set fileA to "Do not download"
• rename fileA to fileA-unwanted (no extra I/O, right?)
• stop (Pause) the downloads from qBittorent
• remove fileA-unwanted from file explorer

[mzso]

@KayLeung

(Can't we bring back distinguishable filenames first?)

You mean like the spammy unwanted folders with (in practice) corrupted files?

If I perform the following actions, what bugs I will face?

You can try it. You'll need to rescan the files because files are missing.

Besides it's not analogous to the problem in question. Downloaded file data is not meant to be lost.

I did suggest once to add a feature to erase files that are unchecked (to free up space). Then only the shared pieces would need to be read and written into the parts file.

[Lewis8379]

I haven't read all of the comments but f me, when I untick sometime to not download, anything already downloaded should be deleted entirely! Should at least be an option to choose this behaviour in settings. qBittorrent cannot be the best client with such a basic problem!

[mzso]

@Lewis8379 commented on 2021. szept. 13. 16:14 CEST:

I haven't read all of the comments but f me, when I untick sometime to not download, anything already downloaded should be deleted entirely! Should at least be an option to choose this behaviour in settings. qBittorrent cannot be the best client with such a basic problem!

It it shouldn't and it never was in any client that I ever used.

[github-account1111]

It it shouldn't and it never was in any client that I ever used.

It is in uTorrent, probably the most popular client in existence.

[mzso]

@github-account1111 commented on 2021. szept. 14. 01:28 CEST:

It it shouldn't and it never was in any client that I ever used.

It is in uTorrent, probably the most popular client in existence.

When I used it it definitely wasn't, so I suspect you're wrong. If memory serves, data was moved into a .dat file.

[github-account1111]

I'm not wrong, but I was using 2.2.1. Could've been changed in newer versions.

[mzso]

@github-account1111 commented on 2021. szept. 14. 22:55 CEST:

I'm not wrong, but I was using 2.2.1. Could've been changed in newer versions.

I've been using that version for years. And from that is where I remember from the things I said.