mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
I know .unwanted folder was meant to be gone, but what's new behaviour supposed to be? #11013
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#11013
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @BattouSaeen on GitHub (Oct 18, 2020).
Originally assigned to: @glassez on GitHub.
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 commented on GitHub (Oct 18, 2020):
It will create .parts files. You may have to show hidden files.
@KayLeung commented on GitHub (Oct 19, 2020):
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 commented on GitHub (Oct 19, 2020):
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:
@KayLeung commented on GitHub (Oct 19, 2020):
It's bad for mis-clicked
a lot of confusion. One of my testings, it leaves a zero bit file
What's wrong with the .unwanted folder?
@thalieht commented on GitHub (Oct 19, 2020):
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 commented on GitHub (Oct 19, 2020):
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 commented on GitHub (Oct 19, 2020):
@arvidn Do you have any suggestions about this?
@qaxifm commented on GitHub (Oct 21, 2020):
.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 commented on GitHub (Oct 22, 2020):
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.
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 commented on GitHub (Oct 22, 2020):
@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 commented on GitHub (Oct 22, 2020):
@arvidn
Please correct me if I'm wrong: the traditional
.partsfiles 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.partsfile, 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
.partsfiles, just the.<infohash>.<filename>.parts.@arvidn commented on GitHub (Oct 22, 2020):
Right, or files could be moved into an
.unwantedfolder, 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 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.
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 commented on GitHub (Oct 29, 2020):
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 commented on GitHub (Oct 29, 2020):
@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 commented on GitHub (Oct 29, 2020):
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 commented on GitHub (Oct 29, 2020):
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 commented on GitHub (Oct 29, 2020):
Your use-case for the
.unwantedfolder 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.unwantedfolder was a welcomed change by most.@BattouSaeen commented on GitHub (Oct 29, 2020):
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 commented on GitHub (Nov 11, 2020):
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:
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 commented on GitHub (Nov 12, 2020):
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 commented on GitHub (Dec 13, 2020):
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 commented on GitHub (Jan 4, 2021):
I vote for an option in the conf file to specify a file path where we want all .parts files to be stored.
@thalieht commented on GitHub (Jan 5, 2021):
Irrelevant to the .unwanted folder and don't make a new issue for it. Find the existing one if you want.
@Knocks commented on GitHub (Jan 5, 2021):
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 commented on GitHub (Jan 5, 2021):
@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 commented on GitHub (Jan 5, 2021):
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 commented on GitHub (Jan 5, 2021):
@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 commented on GitHub (Jan 5, 2021):
Most of us keep download history. That's why
.parts&.unwantedleftover.2 basic needs here:
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 commented on GitHub (Jan 5, 2021):
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 commented on GitHub (May 7, 2021):
Hello, any hope of this getting some love?
@Quantum00 commented on GitHub (May 25, 2021):
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 commented on GitHub (May 26, 2021):
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 commented on GitHub (May 26, 2021):
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 commented on GitHub (May 27, 2021):
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 commented on GitHub (May 27, 2021):
The whole parts thing is complete overly complicated mess. Who needs this? Why?
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?
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 commented on GitHub (May 27, 2021):
@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 commented on GitHub (May 27, 2021):
As the thread starter, my (and those who agree with me - our) request is simple:
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.
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 commented on GitHub (May 28, 2021):
As someone who is not the thread starter but who participated in another thread that people also cared about, my request is also simple:
@ExceptionGit commented on GitHub (Jun 6, 2021):
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 commented on GitHub (Sep 11, 2021):
@arvidn commented on 2020. okt. 22. 10:26 CEST:
What prevents just splicing the existing files to the partfile, without actually copying any file data?
@arvidn commented on GitHub (Sep 11, 2021):
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 commented on GitHub (Sep 11, 2021):
@arvidn commented on 2021. szept. 12. 00:30 CEST:
Ah, thanks for the explanation
I wish. I was just curious about what the technical reason was.
@KayLeung commented on GitHub (Sep 12, 2021):
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?
fileAto "Do not download"fileAtofileA-unwanted(no extra I/O, right?)fileA-unwantedfrom file explorer@mzso commented on GitHub (Sep 12, 2021):
@KayLeung
You mean like the spammy unwanted folders with (in practice) corrupted files?
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.
@ghost commented on GitHub (Sep 13, 2021):
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 commented on GitHub (Sep 13, 2021):
@Lewis8379 commented on 2021. szept. 13. 16:14 CEST:
It it shouldn't and it never was in any client that I ever used.
@github-account1111 commented on GitHub (Sep 13, 2021):
It is in uTorrent, probably the most popular client in existence.
@mzso commented on GitHub (Sep 14, 2021):
@github-account1111 commented on 2021. szept. 14. 01:28 CEST:
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 commented on GitHub (Sep 14, 2021):
I'm not wrong, but I was using 2.2.1. Could've been changed in newer versions.
@mzso commented on GitHub (Sep 14, 2021):
@github-account1111 commented on 2021. szept. 14. 22:55 CEST:
I've been using that version for years. And from that is where I remember from the things I said.
@J-Brk commented on GitHub (Sep 25, 2021):
Seems like he messed up and apparently doesn't even seem to bother to reply to your message.
@FranciscoPombal commented on GitHub (Oct 15, 2021):
The
.unwantedfolder was a way to keep the .parts files stored away somewhere where they wouldn't bother users too much. Now that that is removed, what is being discussion in this issue is "what should we do now with .parts files, now that we know that the previous.unwantedfolder solution did not work?". This means that clearly, #8175 is a subset of this discussion.If you are of the same opinion of the OP of #8175, then all you are really saying, in the context of the general problem of storing .parts files is "the parts files should not be left in the same folder that I save the torrents in". I agree with that, and so do many other people. The big question is then: if not there, then where, and how (in terms of organization)?
@github-account1111 commented on GitHub (Oct 15, 2021):
Make it an option? Either same folder as torrent or a custom location.
I don't really see how this is such a big decision to make.
@mzso commented on GitHub (Oct 16, 2021):
@github-account1111 commented on 2021. okt. 16. 02:41 CEST:
I don't think people usually implement troublesome features of little value haphazardly, because one person cries about it.
@KayLeung commented on GitHub (Oct 16, 2021):
Both using
.unwantedfolder but they're 2 different issues.How to store .parts?
If I/O is a problem to store them in a different drive. Then, add a .qB folder in the same drive and save them all into it. I believed more than half of the users just don't want to see hundreds of
.partsin the main folder. If users don't care about the I/O, they can create a symlink for it.the old UNCHECKED behaviors (aka.
.unwantedfolder)If I/O is a problem again. There's already a
renamefeature in qBittorrent UI. As I suggested above, do a rename action:filename.mp4.unwanted(even has an extra clean-up feature, I think this is still needed before we click that button)A similar suggestion by @mzso. I think qBittorrent needs a
TRUE Completedstatus. ThisTRUE CompletedmustCompleteddownloads.)** I'm still running the version that has
.unwantedfeature but.partsstill saving outside this folder.@mzso commented on GitHub (Oct 16, 2021):
@KayLeung
How does that help?
??? So where do I store them again, "different drive" or "same drive" and which means which?
In the "main" (root?) folder of what exactly?
From where to where? And how does that fix anything?
No idea what you're trying to suggest, this part is pretty unintelligible.
Moving between drives is what causes a lot of pointless I/O. What do you want to symlink and for what purpose?
Creating a .qB folder automatically might not be possible due to permissions. Wherever on the "same drive" you intended it to be.
"Hundreds of files in the main folder" is kind of a mystery as well. QB adds a single parts file to wherever you set the download location.
And giving the user an option to set an arbitrary folder like @github-account1111 is just a recipe for disaster. Sure create a wave of "my torrents are missing files when they don't", and "my torrents stop with an error before they finish downloading", "can't download", and god knows what other issues raised here.
I only suggested the former in a way (which you edited out of your comment). Adding an option to manually remove a partially downloaded file, and maybe a separate one to do it for all such in a torrent.
I don't think automatically removing partially downloaded files is going to happen or should happen. A user might choose to continue them.
What? This is nuts. Of course if you remove download files, or parts files that are necessary to seed a torrent you will get errors.
If a torrent can't bee seeded/continued you should get an error.
@github-account1111 commented on GitHub (Oct 16, 2021):
What are you talking about? I'm not crying about anything. I'm proposing a solution. If you have any constructive criticism to give please do so, but stop throwing meaningless ad homs.
@BattouSaeen commented on GitHub (Oct 16, 2021):
Man what is going on here lol. All I asked for was the .unwanted folder, or a similar behaviour, to come back. That's it. Just the option to have it back, so users who liked how it was before can continue to update and keep the familiar, intuitive behaviour. The merging of two separate threads has made this a big mess imo.
@escape0707 commented on GitHub (Oct 16, 2021):
For real for real.
@ghost commented on GitHub (Oct 17, 2021):
Wow, what a mess.
Basically, if I select a file, even if already partly downloaded, to not be downloaded/skipped, it should be deleted entirely in my view.
@mzso commented on GitHub (Oct 18, 2021):
@Lewis8379 commented on 2021. okt. 17. 17:50 CEST:
That's just an opinion. Others might deselect with different reasons to yours. So that other files would be downloaded first, for example. Also, automatically erasing data without prompting for it is not a popular way to do things.
@ghost commented on GitHub (Oct 18, 2021):
Sure, as is everything on here, an opinion. Of course they will, which is why having an option in the settings for the user to pick their desired behaviour is the best option. Options are good.
@sjlebl commented on GitHub (Dec 8, 2021):
I still have not heard one reason why ".unwanted folder" feature was dropped. I have used it constantly for 6 years.
MANY MANY torrents have multiple files. It is often the case that 10% through, you realize you only wanted 20% of the files. Previously, I unchecked files and then occasionally did a disk index search deleting or emptying all .unwanted folders. Easy.
Now, if I deselect 80% of the files of a 50Gig torrent with 100 total files, when every file has at least 10%, I am left with 40Gigs worth of partial files that I don't want and there is no easy way to get rid of them.
I have NOW changed my setting so that incomplete files have .!qb, but the problem there is that MANY times I have an audio or video file that is mostly downloaded (sometimes 99.0%) and for which the torrent is mostly dead, but that are still completely playable that I don't want to delete.
I would be curious if there was a real reason to remove the .unwanted folder feature or if the programmers of the day just never used it and decided to get rid of it. As a mini-power user, this happens throughout the software industry, where if only 5% of the customer base uses a feature, well just get rid of it.
If we can't have the .unwanted folder back, can we have a NEW extension, like .!un, that is applied when you deselect a file that is already partially or even fully downloaded. Then, at least, the unwanted files could be easily deleted. The current situation of DOING NOTHING when a file is deselected, whereas previously SOMETHING VERY SIGNIFICANT happened when a file is deselected, is the worst of all worlds. It would be better to delete the files immediately TO THE RECYCLE BIN so that a mis click can be recovered.
Removing features that have been around for YEARS and YEARS seems something that should be done as infrequently as possible.
(My other gripe is the great feature where one could optionally place downloads in the watched folder for different torrelts.)
@BattouSaeen commented on GitHub (Dec 8, 2021):
@sjlebl yup, pretty much what I tried to say thoughout that the organisational value offered by the .unwanted folder is amazing, it makes qB a powerful file manager and keeps it all organised. I think I'd be fine with an extension for unwanted files, but I'd definitely just prefer what was never broken to begin with - an unwanted folder. Ironic how wanted an unwanted folder is lol. Like can't there be just a new implementation if it's about partial file code shenanigans? All we want is that unwanted files don't delete upon being unchecked and instead should move to a separate folder. It's powerful and useful. A little extra IO isn't as important to most of us compared to the value offered by the unwanted folder behaviour.
@KayLeung commented on GitHub (Dec 8, 2021):
Let's do it.
most people don't even care about the partial files (and I still don't understand what problem that is here)
As I also mentioned before, now qB has rename features, adding an extra pattern (NEW extension) should be no cons.
I don't code C++ but if we have a solid deal here, I can try to contribute it if it needs help. (I have a glance before, I believe if someone can code C++ and have the tools installed already, it's a quick job. cheers!)
@github-account1111 commented on GitHub (Dec 9, 2021):
It clutters things up. As would a ".!un" file. As does the .parts file currently. Moving to Recycle Bin sounds nice though.
People aren't commenting on why it was dropped because if you want something dropped and it's dropped you generally wouldn't be coming on forums commenting about it, kinda like you only hear bad things about consumer electronics on respective forums because only those experiencing problems post.
@BattouSaeen commented on GitHub (Dec 9, 2021):
IMO moving to the recycle bin is not really that helpful because as outlined in my first post, it keeps the files organised. For example, you may have a torrent that has two different versions of the same file, e.g. one is bad quality but longer/complete, the other is better quality but incomplete (due to whoever encoded it so it's missing say the post-credits scene). So you keep both and you may keep them separate by making use of the unwanted folder. There are better examples and use cases but this was off the top of my head.
If we're going to redo it, then why not just keep the old behaviour? It wasn't problematic the same way as it is when deprecated, so why keep changing it to go to recycle bin or rename? I'd rather there be just a choice to use the old style of having an unwanted folder or the new style of whatever is being done now ... have an option to either move unchecked files (that are downloaded) to an "unchecked" folder (which is the same as the unwanted just renamed).
@github-account1111 commented on GitHub (Dec 9, 2021):
Because come to think of it, the unwanted folder was an extra Recycle Bin which IMO makes it redundant.
IMO a good option would be letting people delete files directly from the Content tab in addition to unchecking.
Unchecking alone stops the download, deleting deletes and unchecks. Which if (once?) #439 is implemented could possibly be a nice "side-effect", since deleting individual files is essentially relocating them to Recycle Bin.
#439 can also take care of your want to compare different versions of torrents.
@BattouSaeen commented on GitHub (Dec 9, 2021):
No you're missing the point - the fact that it was WITHIN scope, i.e. within the folder of a specific torrent, means that it was not just another recycle bin. I keep repeating this - it offered an immensely powerful way to organise and manage files. Those who have managed several thousand torrents know what I'm talking about. So just because you find it redundant does not mean it is and this is why I keep saying there should be an option for those who want this behaviour and those who don't.
The issue you have quoted has nothing to do with what I am talking about and frankly it's apparently as old as 2013 and you can see the author is also exasperated towards the end.
Removing this behaviour has been like removing headphone jacks from phones. Nobody really asked for it, some are fine with it, but many are hurt by this and are therefore not updating.
@github-account1111 commented on GitHub (Dec 9, 2021):
I'm not missing anything. It's just that the part you liked was the part I disliked haha
That it was in the same folder as the actual files was what bothered me (and what bothers me with .parts files).
And implementing #439 would offer a way of doing that too - IMO in a more elegant and streamlined manner.
It encompasses the needs you listed here and fulfills lots of others.
I'd argue this issue is a subset of that one, and implementing both would be duplicating effort, unnecessarily cluttering up the program and complicating maintenance.
I think it would solve this exact need you have (and more).
The ability to relocate files from within qBT would let you relocate the things you wanna compare to separate folders.
That's blatantly not true. Many have asked for it, and it was clear from browsing forums like this and reddit.
@BattouSaeen commented on GitHub (Dec 9, 2021):
#439 has not had anything done there since 2013. So it's pointless to talk about it being a solution to anything or working on this being some sort of waste of effort when there has been no effort put into that issue in the first place. It's a separate issue.
Comparing files was just one example, it wasn't the biggest or most important nor the only one, there are several other examples besides that. I don't want to add more clicks and work to something when just checking/unchecking files solves a bunch of them in less than a microsecond!
Well judging by how many are asking for it to come back you can see there is equal, if not more demand for it. And this is why I keep saying. Give. Users. CHOICE. Everytime software doesn't give a choice, it becomes annoying and frustrating. It was a feature that was in the client and was useful to many. Removing it has just caused a huge chunk to not be able to upgrade and be on the same page. It's creating fracture. It's like many games that hardcode the controls instead of letting users set things up for their own personal needs.
The whole beauty of software is polymorphism and allowing a bunch of things to be compartmentalised and offer variety and customisation.
Again, if you want some other solution, you are free to make a thread on it, but please, I'd like this request to remain as true to its original as possible. The minimum asked for is to have the same behaviour of "unchecking moves file to a separate folder within the torrent's own folder". That's it. It existed already, so it's not some brand new endeavour. And ideally, it should be a choice so that those who don't like this can switch it off/disable it so that everyone is happy.
@github-account1111 commented on GitHub (Dec 9, 2021):
What does the age of an issue have to do with whether it's pointless or not to talk about?
It's still open.
That's all that matters as the potential of implementation is the same as with any other open issue.
If anything, it's higher because FWIW that one is currently sitting at 35 upvotes while this one only has 1.
Don't know what demand you're talking about.
List them then. That would only help, because as is, this seems to be redundant.
Moving takes about as long.
Not sure what you're trying to say with this.
@BattouSaeen commented on GitHub (Dec 9, 2021):
The age has to do with it because if nothing has happened for nearly a decade then it's dead lol. Upvotes don't matter. What matters is whether devs wanna do it or not.
Why are you telling someone who USES the feature that it's redundant? This is once again one of those annoying Linux memes of "just use the command line". No. We want choice. Especially one that existed. If YOU don't like it, DON'T USE IT, but don't make it miserable for others.
If you couldn't understand what I meant by that polymorphism then why are you telling me to use something else? The point was that give options.
@BattouSaeen commented on GitHub (Dec 9, 2021):
The age has to do with it because if nothing has happened for nearly a decade then it's dead lol. Upvotes don't matter. What matters is whether devs wanna do it or not.
Why are you telling someone who USES the feature that it's redundant? This is once again one of those annoying Linux memes of "just use the command line". No. We want choice. Especially one that existed. If YOU don't like it, DON'T USE IT, but don't make it miserable for others.
If you couldn't understand what I meant by that polymorphism then why are you telling me to use something else? The point was that give options.
@github-account1111 commented on GitHub (Dec 9, 2021):
If it were dead it'd be closed.
Because it is redundant.
Whether you are someone who uses it or not is irrelevant.
I said I'm not sure what you're trying to say, not that I don't know what polymorphism means.
To put it another way, you aren't making much sense.
No idea what's up with the Linux meme part either. Sounds like some sort of virtue signaling.
@BattouSaeen commented on GitHub (Dec 9, 2021):
Lol dude please leave this ticket, it really isn't for you since you are here telling someone who wants water in a glass to go swim in an ocean and drink from there instead. This request is a simple one, which is to restore the original behaviour and in light of modern direction, give a choice to either enable or disable it. You saying it's redundant doesn't make it redundant. You're the only one not making sense because as I mentioned over and over again, this is about asking for the original behaviour. If it doesn't make sense to you then maybe you should go to some other issue.
@github-account1111 commented on GitHub (Dec 9, 2021):
I'm not just saying it's redundant, I'm also explaining how it is redundant.
I'd also appreciate it if you stopped telling me where I can and can't be.
If you don't want others commenting on your issue, then don't create an issue in the first place.
@BattouSaeen commented on GitHub (Dec 9, 2021):
My Lord can you like go elsewhere? Going around telling people they should not want something for YOUR REASONS is the most toxic and wasteful thing ever. Offer a solution. No, you telling to merge with an 8 year old dead issue, where the author is as exasperated as I am now, is not a solution.
You can be wherever you want, but if you're gonna go around putting others down just because YOU don't find any use of a feature THEY are asking for, then you should probably not be surprised with the responses you get. I don't know why you're here, what are you gaining out of it other than trolling and wasting responses where someone can better offer a solution like KayLeung above did before you came and began with imposing your own version on someone else's feature request? So yeah, kindly leave this issue alone, it's not worth your time or input.
@mzso commented on GitHub (Dec 9, 2021):
@BattouSaeen commented on 2021. dec. 9. 16:39 CET:
Not it didn't it. It was buggy unneeded and often spammed empty .unwanted folders unnecessarily all the time.
You just adapted some use case wholly based on .unwanted.
Reminds me of:
@BattouSaeen commented on GitHub (Dec 9, 2021):
@mzso I have almost never had these empty unwanted folders, ever. If I ever did, then those were populated with the files that contained the edge/part files for the main file. And how is having billions of junk partfiles better than a single folder housing the "unneeded" files? Makes no sense.
It is not just me who "adapted" it, it's literally a direct consequence so it doesn't need any adaptation by those of us who make use of it nor does it cause us any issue. I mean the point of this whole topic is literally the fact that it offered value and now without it, it doesn't offer that same value and instead makes it harder by forcing a binary interaction with the client. With the unwanted folder you are free to organise files depending on what you want to do, with a single click rather than going in manually into a folder. This has been repeated over and over and over again by multiple people.
That little meme is irrelevant and silly. Again ... we just want the ability to have unchecked files move into a folder within the torrent's subfolder just like the unwanted folder behaved. THAT is all. I don't understand the problem with this. Developers are free to make this as optimised as they want (as they should, I'd wanted to for sure if I were responsible). Give users choice. Why is this such a problem? Nobody is asking for the bugs of the unwanted folder. We're asking for the uncheck -> move to folder, recheck -> move back to main area behaviour.
Meanwhile when I originally updated without knowing about this change, all my folders are polluted with gazillion garbage parts files and broke so many things.
@BattouSaeen commented on GitHub (Dec 9, 2021):
It's so crazy for you to just say "no it didn't [offer ... ]" to us who DO find it useful, just because you yourself don't find it useful. Makes no sense. It's like someone says "I like keyboards with numpads, they offer me an easy way to ... " and then telling them "no it's large and takes up space on the keyboard." lol.
@mzso commented on GitHub (Dec 9, 2021):
@BattouSaeen commented on 2021. dec. 9. 19:30 CET:
All requests are simple. Doing is what's hard. It was removed with quite a bit of pain. And doing it concurrently with with a different solution to the same problem more that doubles the complexity. The feature was buggy to begin with.
Maybe you should be more grateful for suggestion of doing things other than with a feature that doesn't exist anymore.
Don't expect a feature being reintroduced just because two individuals complain about it.
@BattouSaeen commented on GitHub (Dec 9, 2021):
@mzso I can code, so I understand what you are saying. I don't have you at gunpoint asking for the feature but there is no easy explanation offered yet as to why it is so complex to implement. Forgive me for saying this since I speak out of ignorance since I am not part of the team and don't know the structure, but we're talking about move instructions and making directories based on whether a file is checked or unchecked. The main thing I don't know is how it's playing with partially downloaded files which the unwanted folder retained (progress of downloads), but at best it's just moving of files.
Grateful for what suggestions? There is only one way of having an unwanted folder behaviour and that's by sticking with older versions of the client. And that's again what we are asking for since it doesn't exist in the latest builds. This thread started more than one year ago, so this is really not about it being complex, it's more of a unilateral decision, the same things we complain of with MS or other software giants when they change something that so many have been used to and actually making use of.
@BattouSaeen commented on GitHub (Dec 9, 2021):
Judging by some of these replies, I doubt this will be fixed, which is an absolute shame. It means minorities will get ignored, which we all ignore until we become minorities and then it just keeps going on in a cycle until someone breaks that. So I hope a developer who is sympathetic to this issue will one day implement something to offer this same functionality, perhaps even better than this, but the least we are asking for is just move operations. So whoever you are, thanks in advance and I will personally be happy to contribute myself to it if possible, but I feel I will be more of a hindrance than help and sometimes that is an important consideration to make upon self-assessment of skills.
@Chocobo1 commented on GitHub (Dec 9, 2021):
Not trying to join the discussions, just leaving a pointer for those who are interested in code.
The code for this feature doesn't reside in qbt code base, it is in libtorrent and the feature is named
part_file.Also the libtorrent author joined this thread earlier and left some comments, worth a read.
@github-account1111 commented on GitHub (Dec 11, 2021):
Why is it toxic exactly?
Why isn't it?
I'm trying to be objective and keep it civil, but your knee jerk reactions to everything I say and your childish behavior are making it very difficult and derailing everything.
The lack of self-awareness is honestly funny.
You're doing all the things you're accusing me of.
Why don't you follow your own advice and
@BattouSaeen commented on GitHub (Dec 11, 2021):
Go back and read from your first message and my reply to it. Is that a knee-jerk reaction? No. At the end, which should have been the end, I said
"Again, if you want some other solution, you are free to make a thread on it, but please, >>I'd like this request to remain as true to its original as possible.<< The minimum asked for is to have the same behaviour of "unchecking moves file to a separate folder within the torrent's own folder". That's it. It existed already, so it's not some brand new endeavour. And ideally, it should be a choice so that those who don't like this can switch it off/disable it so that everyone is happy."
The part between the >> << up there.
But you keep going on, asking why I feel like the issue you quoted is irrelevant and I repeatedly answered in a simple manner that it's an ancient, neglected, dead issue where the author himself/herself has echoed this and yet YOU want to impose your own thought on the matter, rather than listening to the author of this thread, who does not agree with your suggestions, but you keep trying to change their mind on it.
This is why it's become toxic as you're not letting it go. You are welcome to give suggestions, but if your suggestion is not in line with the original idea of having the same behaviour as before back, then it's kinda pointless and it's better suited to be in its own thread as a separate feature.
Nothing about what you say is objective, other than the .unwanted stuff being buggy, which was already talked about by the author of libtorrent way earlier.
Why should I go somewhere else when I am literally in the post I started? Notice how many posts of yours have others with thumbs-down. Notice the many qbittorrent forum threads or reddit threads where people express they wish they had this feature back.
Anyway, I reiterate and I have no desire to continue arguing with you on this because you are not in support of this feature, but the majority of us are, because the thread literally is in support of it.
In fact, the current versions of this do not have the feature to begin with (prompting this thread), so you coming here just to tell someone to stop asking for something is indescribably weird. You've gone out of your way to go tell someone to not request for a feature which the program doesn't have currently. It would've made an iota of sense had this feature still been there and I was asking for deprecation because then functionality is being removed, but here it doesn't exist and we are asking for it back. We're not asking for the bugs, we're asking for the utility/functionality. It literally doesn't harm you in any way shape or form, yet you are championing making other users have a worse experience at the cost of no improvement to your own.
Anyway, thanks for your input, but please, no more, too many off-topic replies now.
@jarfil commented on GitHub (Dec 11, 2021):
@sjlebl
Sounds to me like what's desired is having access to the list of selected/deselected files, so an external tool may decide what to do with them. Maybe an alternative to an .unwanted directory could be an API, or other way of exporting that information.
Additionally, a "delete file" feature could at the same time keep the parts still required for verifying the adjacent files (either migrate them to a parts file, or rename to .!qB and punch a hole for the unwanted parts, or migrate them to a .!qB file), while releasing the disk space used by the unwanted parts.
An API that would allow both of these actions, could enable an external tool to manage files any way a user might want.
@arvidn commented on GitHub (Dec 11, 2021):
Just to clarify. part files is a feature of libtorrent. Before libtorrent had support for part-files, it was up to clients to move unwanted files aside, which qBT used to do in the .unwanted folders. So, the .unwanted folder was a feature of qBT. I can imagine having both features at the same time making sense, but I can't comment on the complexity (and reliability) of the unwanted folder feature. I assume there was a good reason to remove it. At least some, maybe most, of its value disappeared once part-file support was added to libtorrent.
It's very easy to underestimate the amount of work it is to implement a feature. Especially taking into account all the ripple-effects it might have for years to come, as it interacts with other features. This is a problem among software engineers and even more so for non-engineers.
The BitTorrent protocol doesn't support telling a peer that we no longer have a piece that we previously said we had. This doesn't make it impossible to delete data that has been downloaded, it makes it more cumbersome. You would have to disconnect peers for instance. Some users may then be surprised that peers are disconnected just because they deleted a file. The farther you go against what's natively supported by the protocol (and other peers), the more awkward (and unintuitive) quirks you have to deal with.
@KayLeung commented on GitHub (Dec 11, 2021):
@arvidn,
A perfect deal is cool. But if it takes more than 1 year or forever, I'd trade off something to get the job done. Somehow, I can understand it. If I'm the author, I may not add it to libtorrent but I will do it in qBT.
Sorry, it's unclear. It was referred to a rename alike feature I (or previous comment) talked about. This is a UI binding more than a new feature / API.
In fact, I am always surprised we can't put files anywhere freely. (Is it qBT, libtorrent, or BT spec limits?)
And some of your concerns wouldn't a problem for me and most users who needed
unwanted-alikefeature I believe. After removing unwanted, unselected files still remaining in your disk. Now, when I removed that unselected/downloaded files, the same problem happened, right? So the only problem is the extra IO you described in the previous comment.In the past before I have my own script to manage files, all files are 100% downloaded and have been written to disk before I have time to unselect it. In this case, we have no extra IO to move it to
.unwanted. I also believe major users doing the same.(Actually, when I know more about how part_file works, I started to remove my torrent download history. It's bad for me but I have to do it to release the disk space. So yeah, a perfect deal is still needed.)
(From a user perspective, many behaviors are non-sense. For example, to re-scan a completed & stopped torrent is wrong. The re-scan should only happen on torrent restart/reseed. Or saying that part_file still remaining on the disk for completed torrent is bad.)
@jarfil
@see: https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-(qBittorrent-4.1)#get-torrent-contents
unchecked is
priority=0@arvidn commented on GitHub (Dec 11, 2021):
I don't believe libtorrent has such limitation. What happens when you try?
That sounds like a bug. Unless you refer to the re-scanning after deleting some files belonging to the torrent and restart the client.
@KayLeung commented on GitHub (Dec 11, 2021):
@arvidn
I mean when I download a torrent with 2 files. I want to put
FileAto/A/FileAFileBto/B/FileBIf it works, a batch action to set location better than specified
.unwantedfolder.** Below is off-topic. Others can skip it. Sorry for the noise. **
now:
I expected:
@arvidn commented on GitHub (Dec 12, 2021):
it sounds like you would like qBT to set the
no_verify_filesflag when loading resume data (docs).@sjlebl commented on GitHub (Dec 17, 2021):
So, I'm confused about the level of emotion and vitriol.
I am asking for and MANY MANY YEARS OLD FEATURE (from a few months ago) that was crucial to my ability to have a few hundred torrents running and seeding for some private torrent groups I am in.
Now, this feature is important to one specific situation. I start download of a torrent with multiple files (lets say 5 to 200). I get around to looking at the torrent 5 minutes later and realize I ONLY WANT 10% of the files in the torrent.
What USED TO HAPPEN, like 6 months ago, was I unchecked the files I did not want (or often UNCHECKED THEM ALL, then reselected the files I did want), those files were moved to a .unwanted folder in the download directory of the torrent, AND i could easily delete the whole folder in explorer OR use a searcher to delete ALL .unwanted folders.
What HAPPENS NOW is NOTHING. So if 180 of my 200 files in ONE TORRENT are unwanted, they just sit in the download folder, taking up full size. I have no way to distinguish them from the 20 files I actually want. So, qBitorrent went from something useful happening to NOTHING AT ALL happening, leaving 100s of orphaned files in my download structure with no (ZERO) easy way to identify them or get rid of them. THE OLD WAY FOR AT LEAST 5 years till 6 months ago worked great FOR ME. There IS NO WORKAROUND for me now. I am just STUCK WITH FILES I DON'T WANT.
So, rather than telling me I don't need what I need AND HAVE BEEN USING HAPPILY FOR MANY YEARS, tell me to F.O., and I will downgrade, or tell me some option that ACTUALLY WORKS for my situation.
Just to quench my piqued curiosity, if anyone knows WHY, other than whimsy, a feature that so far as I know was causing NO PROBLEMS was deleted, I'd like to know that.
But, telling me about parts files, which is irrelevant to this issue, about about individually relocating each of 180 files, or something else, just isn't helpful. You ask why I want it. I tell you. You either give me a workaround THAT works, or a too bad. But, arguing that what I KNOW TO BE VERY USEFUL TO ME is in fact not useful to me is not respectful or helpful.
Thank you. I know this is free software and I am delighted to have people invest their time into writing it, but USERS also invest their time into LEARNING the software and making it work for THEIR NEEDS. When a handful of programmers gets rid of a VERY OLD feature cuz THEY don't use it, you are (possibly unnecessarily) inconveniencing and discouraging long time members of the community. If someone tells me, oh, it was going to be a HUGE PROJECT to maintain this feature, fine, I understand. But, no one has yet said that.
AGAIN, however clunky or stupid or redundant the .unwanted folder was, replacing it WITH NOTHING...NO ACTION...just leaving the unwanted file in place without a name change or anything else, seems the WORST possible option.
@BattouSaeen commented on GitHub (Dec 17, 2021):
@sjlebl
Yep pretty much similar case for me. The only thing I can say is that the partfile behaviour is related to what happens when you unselect a file, that is, the amount of IO and whether or not it is still required by peers who are sharing the file. I'm not terribly understanding of it either. I hope Arvid can someday figure out a way to incorporate a simple behaviour to move unchecked files to a folder like the unwanted folder because based on the development. I don't mind the extra IO personally, I only need the uncheck -> move to subfolder behaviour as I'm sure you do as well :)
@KayLeung commented on GitHub (Dec 17, 2021):
Personally, I doubt the extra HEAVY IO has happened. When I unchecked a 10GB file (30% or 100% finished) on slow HDD, I can play it from .unwanted immediately.
@arvidn's first comment actually telling we put the cost already. And his following comment:
So, when the extra (HEAVY) byte-to-byte COPY & WRITE is happening?
If that's only a few KB of first & last piece. Is it matter? Might be libtorrent designed to serve 100000000 files at the same time but I think qB is just a simple end-user software.
@mzso commented on GitHub (Dec 31, 2021):
@KayLeung commented on 2021. dec. 17. 09:44 CET:
What are talking about? He was saying that if pieces needed to bee moved in or out of the partfile it would require copying and deleting, even if it's a fully finished but unchecked file. That's a hypothetical scenario because right now in QB only pieces for unchecked files are stored in the parts file, unfinished or finished unchecked files are left in place.
@dsmadja commented on GitHub (Jan 11, 2022):
Simply wanted to tell that I also, appreciated the ".unwanted" functionality of the previous versions, and would also like to somehow have a "uncheck -> move to subfolder" behaviour back.
Same reason as others : when downloading multiple files torrent but needing only some of them, it was great to be able to simply uncheck files not needed, and see them being automatically deleted when removing the torrent after download.
Hope to see a similar functionality in next versions (which never generated any visible issue -IO load or whatever- on my end)
And, while I'm at it : many thanks to the developers for this great tool I am using for years now !
@mzso commented on GitHub (Jan 11, 2022):
@dsmadja
That's still how it works, only without .unwanted folders.
@escape0707 commented on GitHub (Jan 11, 2022):
@mzso AFAIK, set a file to "do not download" after it's already downloaded won't delete it at all. And then if the user manually delete the file they will need to recheck and redownload those "unwanted" pieces too be able to seed adjacent files correctly.
@mzso commented on GitHub (Jan 12, 2022):
@escape0707 commented on 2022. jan. 12. 01:47 CET:
It will be deleted "when removing the torrent after download".
@dsmadja commented on GitHub (Jan 12, 2022):
Thanks all. I'll try again, but I came here precisely because unchecked files were not deleted after removing the torrent (which is my usual use case).
@mzso commented on GitHub (Jan 14, 2022):
@dsmadja commented on 2022. jan. 12. 12:22 CET:
So only partial files are removed? I'm not certain anymore.
@sjlebl commented on GitHub (Jan 20, 2022):
So, I was just checking the release notes and the release JUST BEFORE
.unwanted folder was removed by
"
seems to be
Saturday April 25th 2020 - qBittorrent v4.2.5 release
I am planning to downgrade to that. Wish me luck.
Peace and warm regards,
Stephen LeBlanc
On Fri, Jan 14, 2022 at 3:21 PM mzso @.***> wrote:
@KayLeung commented on GitHub (Jan 21, 2022):
@sjlebl
YES. that is v4.2.5. I'm still using it.
@tworepetae commented on GitHub (Jan 21, 2022):
Same here, haven't upgraded since that change. Too useful of a feature to not have.
@NeoTheOne commented on GitHub (Jan 25, 2022):
If I want to seed something but not have the files in the folder structure this was perfect, don't really know what to do now besides stay on 4.2.5.....
@mzso commented on GitHub (Jan 25, 2022):
@NeoTheOne
That's far from a reasonable usage case.
Are you sure those files are even seeded by QB, likely they are not.
Move the torrent into a folder out of the way...
@NeoTheOne commented on GitHub (Jan 25, 2022):
@mzso
Don't want to go too much into it but this is on private trackers where your client has to present all the files on a torrent as available for the torrent to count as seeding.
And because of that reason I'm also fairly sure that the files are seeded by QB.
How I do it is download 100% of the torrent and then uncheck stuff like openings or extras so that I can still seed them without my Plex scanner finding the extra content and get stupid ideas.
I could technically put a period in front of the filename of all the files I don't want the scanner to interact with instead now that I think about it.
Just have to play around with the plexignore filter...
@sjlebl commented on GitHub (Jan 28, 2022):
SOME users of qbittorrent on private trackers have 8000 active torrents
running and might MANUALLY download 10 torrents a day.
Again, unchecking a file PREVIOUSLY did something to make the file easy to
delete...like MOVE it to unwanted. Now, unckecking a file DOES NOTHING AT
ALL. So, if I download a torrent of 100 10GB files, but know I will only
select 10 of them, by the time I start reviewing it, maybe ALL the files
have downloaded something, leaving 1T of occupied space. When I determine
and uncheck the 90 (though in this case, I would uncheck ALL then check the
10 I wanted) I don't want, NOTHING HAPPENS. The files are not deleted,
moved, or marked IN ANY WAY. So I have 90 10 Gig files in the download
folder that I have to determine, 1 by 1 the titles of to figure out which
ones to delete. PREVIOUSLY, I just deleted the whole .unwanted folder after
checking only the 10 files I wanted. Actually, I wanted till my disk was
90% full and deleted ALL .unwanted folders with 1 script.
Again, right now, NOTHING indicates, in the file system, WHICH TORRENT
FILES are selected and which are unselected.
That is bad.
Peace and warm regards,
Stephen LeBlanc
On Tue, Jan 25, 2022 at 10:25 AM Charlie Skog @.***>
wrote:
@BattouSaeen commented on GitHub (Jan 28, 2022):
@sjlebl I think what some are missing out is that some of us don't want to delete the torrent afterwards, so the new behaviour of not having an .unwanted folder, but deleting the unwanted files after deleting the torrent, is actually not applicable since we're not deleting the torrent afterwards.
@sjlebl commented on GitHub (Jan 28, 2022):
Thanks for the clarification. I was starting to suspect this when someone
mentioned using sonic or some other auto downloader.
I keep 80% of the torrents I download, for a number of reasons, partly
because I use some private trackers that make impossible to find videos
available. Especially since 8T drives are $100.00
Peace and warm regards,
Stephen LeBlanc
On Fri, Jan 28, 2022 at 2:44 PM am117 @.***> wrote:
@BattouSaeen commented on GitHub (Jan 28, 2022):
@sjlebl yup, sadly this is why we're all stuck on 4.2.5. It's already been two years, but I hope one day someone generous with their time can accomplish this.
@KayLeung commented on GitHub (Jan 29, 2022):
I'm not sure if I read it wrongly? I tested the latest MacOS version beta a week or two ago to see how the newer version works. Deleting the torrent WILL NOT delete any unselected files. (this is another bug then)
Surprisingly, I don't see any partfile on MacOS or hidden somewhere? Also, I am still able to play the 50% incomplete video immediately. Wish someone generous can explain how partfile works in simple English. Above comments are totally different than what I see on my real tests.
Also, another point I don't quite understand. If all temp is saved in partfile until 100% downloaded, why do qB / libtorrent try to create another temp file in folders before actual write out?
@thalieht commented on GitHub (Jan 29, 2022):
.parts files (which are hidden) are for putting the cross-file-pieces (not entirely sure if this is their only purpose) that have to be downloaded anyway because they belong to 2 files, one of which is deselected before any piece belonging to that file is downloaded. If any such pieces are downloaded before the deselection, there is no way to put them in the .parts file and the deselected file will be created (but will contain only the pieces downloaded so far). The .unwanted folder was for putting already downloaded (or partial) files after they are created by deselecting those files. See https://github.com/arvidn/libtorrent/issues/3397 for .parts.
Given the explanation above, this is obviously false.
@mzso commented on GitHub (Jan 30, 2022):
@BattouSaeen commented on 2022. jan. 28. 23:44 CET:
I actually made a request solving this when .unwanted was still present: #9923
But it was closed and immediately locked by @FranciscoPombal so no once could respond to it, when the .unwanted feature was removed.
Claiming falsely it's "not applicable", even though it very much is and by the looks of this issue more so than it was before.
Besides this, I actually don't think moving stuff into a folder when unchecked is a bad idea, but not how .unwanted did it, which sometimes sprouted a bunch of empty folders and/or folders for each separate unchecked file.
Occasionally it caused unexpected data loss. (when I moved completed files from elsewhere into the torrent folder, then re-selected it in QB so I could recheck it. But it was owerwritten with the partial file from .unwanted)
We have a
hashcodefolder (or whatever you want to name it) instead of a<hashcode>.partsfile in the torrent's root.It would be a single folder, not mixed into the respective torrent's folder structure. And all unwanted files folder could be moved there retaining their tree structure, as wall as a parts file if necessary. But it should be done well NTFS permissions wise as well, with not giving "read" access to other programs besides QB. (usually there's no need to )
@KayLeung commented on GitHub (Jan 30, 2022):
this statement is FALSE. Deleting the torrent, remove the parts only. No other further actions of unselected files. a BUG?
Thanks @thalieht but I'm not really sure if I understand it or not. It really looks like a simple problem to me. And the below comment told something even more interesting.
https://github.com/arvidn/libtorrent/issues/3397#issuecomment-435424923
Let's simplify it, if we do the below action, any problems?
mv fileA .unwanted/fileAI guess the extra IO is: (this isn't implemented in the current version? on planned roadmap?)
50% downloads and in parts, 30% write out to file. now unselected it. Starts to write remaining 20% to
unwanted (if we have unwanted feature)For most users, I think the remaining 20% of unselected files are useless. It need not write to disks.
(remember that, no matter new or old version still leave that 20% in part if I'm right. I don't see the IO on my disk :s anybody able to second confirm about it also? )
Then introduce 1 or 2 buttons to release the HDD space:
PURGE PART- remove parts withOUT writing to diskWRITE to disk (unwanted)- write to disk. USELESS? Just like what I said above, if you need it, no reason to unselect it.@BattouSaeen commented on GitHub (Jan 30, 2022):
@mzso
It's good to hear you made a request back then but we are obviously not aware of it if it were locked immediately, nor can everyone keep up with everyone's individual threads. But why do you always counter with "no you're wrong"? The reason I'm saying it's not applicable is because a lot of us don't remove the torrent. So removing the torrent being a solution for removing unchecked files is irrelevant. In fact, most of us don't even want unchecked files treated like this (that they are all mixed with the downloaded files instead of being in a separate subfolder in the torrent's own directory), so it's still not applicable. If you feel it is applicable then that's YOUR usecase and it's legit, but not true for everyone else.
In the nearly 10 years I've been using qB, I don't think I've ever run into the ghost/empty folders. Maybe it happened way back in the day, but in the past 5 years I have never noticed a separate empty folder for each separate unchecked file. The only bug I can think of which happens every now and then is where it makes a ghost folder of the entire directory of the same name but that only happens if I'm renaming the folder many times in qB and at some point it stumbles and fumbles, but the solution is more or less simple where I just remove the torrent and add it back to the list via magnet or file and it rechecks and everything is in order again.
In any case, we're not lobbying for the unwanted folder to be implemented exactly how it was under the hood. We just want there to be a folder inside the main folder of the torrent, which would house any unchecked files. So if a torrent has the folder "C++ Tutorials", then any unchecked files will go into "C++ Tutorials/unchecked" or "unwanted" as before. But under the hood of course given the opportunity it should be improved as you mentioned all these bugs which I personally never came across but I'm not gonna challenge them since all software is buggy.
I dunno, this still only goes halfway in solving the problem and creates a new issue. When you have several thousand torrents, it's a pain to have to go to ANOTHER folder elsewhere that has the same directory duplicated only to house an unwanted folder, meanwhile the original download folder of the torrent does not have the folder. Doesn't really sound so good practically in terms of UX.
Actually, maybe it's good for the .partsfiles because those are the files nobody wants to see or touch and the ones that pollute the directories if you have hidden files enabled, so I'm all for removing .partsfiles from sight lol.
@sjlebl commented on GitHub (Jan 31, 2022):
I DELETE any empty folders once every few months in my torrent folder
structure, with 1 right click. Empty folders don't seem to be a problem I
have ever worried about.
I've rarely had a problem LOSING a downloaded torrent to overwrite when
moving or renaming files or folders in qBitorrent. I've learned to be
careful about it.
I don't care HOW qbitorrent distinguishes unchecked files or folders in the
UNDERLYING FILE SYSTEM, so long as it does. If there is something awful
about an .unwanted folder, then add an extension, like !un. Just, ANYTHING
so that I can BULK DELETE potentially 100s of files taking up 100s of GB of
diskspace.
Again, the CURRENT BEHAVIOR is to DO NOTHING AT ALL to in any way indicate
in the underlying file system that a file has been unchecked or marked DO
NOT DOWNLOAD. This is awful behavior for anyone who downloads torrents with
many multiple files, then reviews and unchecks unwanted files.
I do not know or understand what the big PARTS file issue was. I have used
the /.unwanted folder for maybe 8 years and never found any problems with
unwanted under the hood files being left around. I also am not aware of
ever having downloaded torrents with with shared parts files, but I have
never experienced bad behavior due to that when unchecking files.
I am a former programmer, and just a user. I am very familiar with
programmers who delete or remove feature that THEY AND THEIR IMMEDIATE
circle don't use, assuming that the OTHER 75 million plus users don't use
them either.
While I am griping, I also ROUTINELY used the feature of downloading
different torrents to the WATCHED folder of the torrent file. While magnet
links are GREAT, many many private trackers still use .torrent files. This
was a GREAT feature, since many browsers keep per website history of the
last download directory. So I could easily organize torrent files from
different private trackers. Like .unwanted, this feature, which seemed
easy, intuitive, and bug-free IS GONE. Apperently, I could use CATEGORIES,
but I have never done so, as I never needed to. Why DITCH a feature than
untold 10,000s of users might have used, that was working fine.
I KNOW that qbitorrent is a labor of love by its programmers, and I AM
GRATEFUL, BUT HAVE SOME RESPECT for the programmers who came before you
BEFORE you delete features that work find....AND ALSO FOR THE USERS.
And, please, stop COMPLICATING simple questions or requests. Several people
have been VERY CLEAR about why the .unwanted folder feature was important
to them. NO ONE has answered as to 1. Was it horribly buggy? (not for
users), 2. Was it very hard to rewrite into the current qbitorrent? or to
just PUT BACK? (Maybe, though without any specifics, I don't understand why
it would be), 3. What could be done in accordance with whatever new
problems or philosophy of the current qB programmers TO ACTUALLY FIX THE
PROBLEM for USERS that removal of this feature has caused.
Thanks again to the programming staff, though I would be NICE if one of
them responded on this thread.
.
Peace and warm regards,
Stephen LeBlanc
On Sun, Jan 30, 2022 at 12:02 PM am117 @.***> wrote:
@mzso commented on GitHub (Jan 31, 2022):
@BattouSaeen
You're becoming too ranty, and don't bother interpreting what you're responding to.
I wasn't in any way referring to you. I was talking about the closed issue and quoted from the final comment by Francisco. He said it was not applicable, which is obviously wrong.
No it was happening in 2018 and were never fixed, but such issues were closed because the .unwanted feature was removed not long after. Such as #7379, #4447
Halfway how?
Also, not only it wouldn't be in another folder but the torrent's save folder. But there's zero reason for you to be mucking about in the folder. It's for QB to use, if you want a file you'd just enable that file. If you want to free up space you remove the torrent from the client, there's no other option unless they decide to implement #9923. (a separate issue)
But it would solve the unchecked files/folders being there.
@mzso commented on GitHub (Jan 31, 2022):
@sjlebl
How does that make sense? Just remove torrents that you don't want to seed and they'll disappear.
@sjlebl commented on GitHub (Jan 31, 2022):
@mzso
Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh!
Several people, including me, have explained this AT LENGTH, at least 15
times. Just briefly review the thread.
Deleting the torrent does not delete the unchecked files unless you have
that option selected and sometimes even not then.
Some single torrents have 100 files in them. I only want to delete the
unchecked files.
Peace and warm regards,
Stephen LeBlanc
On Mon, Jan 31, 2022 at 12:52 PM mzso @.***> wrote:
@mzso commented on GitHub (Jan 31, 2022):
@sjlebl commented on 2022. jan. 31. 23:49 CET:
I keep forgetting that. Any way, the problem is mainly your bad habits. Don't start downloading everything all the time just to uncheck 90% of them.
And especially don't start thinking about clean-up when you created a wast number of torrents like that. If you know to uncheck them you can just as well delete them in the filesystem instead.
Granted a "remove unchecked" feature would help, but that fell on deaf ears. (Apparently Francisco Pombal expects the same issue to be recreated whenever he decides to eclectically close and lock one that was not addressed in any way.)
You can create a new issue for that if you want. I'm in no mood to copy/paste my old issue.
@BattouSaeen commented on GitHub (Jan 31, 2022):
@mzso
I'm not being ranty. Now I can't just explain things on a forum that is meant to allow users to express their opinions/requests? Literally nothing I said was a 'rant'. I dunno how you consider things as such. If you're speaking about the "not applicable" confusion, is it now also suddenly unforgivable for genuine confusion to happen especially when Francisco and I used the exact same words and you only quoted the "not applicable" part?
That ghosting folder behaviour is ancient which as I mentioned has never occurred in recent times so it has no bearing on what we are talking about. I don't know why but you refuse to understand what is actually being asked for and continue to tell us how we should be using the application a certain way, which is impossible. Again, for the millionth time, nobody here is asking for the bugs to be back. Everyone IS asking for putting unchecked files into a subfolder. That's it. Literally that's it. We, the ones who want this feature, do not mind any extra IO because for us the value of the behaviour is greater than the value of saving on IO. And ideally this is resolves if there is a simple option to choose what you want. Instead you're going around thumbs-down-reacting on my post which is describing that we're using an older version and hoping devs implement our request.
"there's zero reason for you to be mucking about in the folder"
... just what
As @sjlebl has said, several people have explained in detail everything and the common request is to have the unchecked files go into a subfolder. That's it.
Now you can say it's up to libtorrent to reimplement this? I don't know. But that would be better than telling "you're using it wrong! Use it like me!"
@BattouSaeen commented on GitHub (Jan 31, 2022):
@mzso
"Don't start downloading everything all the time just to uncheck 90% of them"
This is exactly the problem here where you are not considerate of how in many cases this is impossible to ignore. Many old torrents are just magnet files which means either we wait an unknown amount of time for qB to hopefully download the metadata in order to see what the filelist is, or we add it to the queue and keep it alive so that we can go do other work. This is how you end up with torrents that eventually find the metadata, sometimes it takes months to years even. And then we see the filelist which might be full of junk files that need to be unchecked. Without the .unwanted folder, the main directory remains a mess with junk files and becomes hard to navigate. With the unwanted folder everything just goes into it and we can delete those files -> recheck the torrent -> redownload only those junk files that have the parts in them necessary for the main file.
@mzso commented on GitHub (Feb 1, 2022):
@BattouSaeen
Ironically you're even more ranty. :) No need to waste more words on this, it's meaningless.
Just because you hand-wave it, it was never fixed and because of that it happens just as it always did. I guess you didn't bother to look into the linked issues and recreate them.
? Why bother reacting anything, if you can't form a proper thought/sentence. That hypothetical folder is for QB to store stuff, not for the user.
Where do you get this? .unwanted was a QB feature.
Well, this is senseless. You just spam your client with dead torrents, and leave them there for years, and sometimes some of them, when you long forgot all about them download a little bit of data and you end up with junk files. Of course there's no realistic chance for such torrents to be fully seeded after they were dead for weeks/months.
You create most of your own problems. If you don't want to use QB logically, then you have to deal with the consequences on your own...
I wouldn't mind a" removal of unchecked files" feature (I opened the issue on it), but I can deal with it. I also would prefer if unchecked files wouldn't remain there, especially incomplete files, but I can live with it.
Also it would be nice if the metadata could be loaded (such as adding in a paused state) without the torrent starting downloading immediately. But in practice it doesn't matter much if it doesn't load in a reasonable amount of time it's dead and can be removed.
@BattouSaeen commented on GitHub (Feb 1, 2022):
@mzso
Look if you feel I'm 'ranty' then just ... don't take part in the discussion then? A rant would be if I were saying angry things and cursing the devs, which I'm not.
I looked into the issues and I could not recreate it. The only person who has been hand waving several members here has been your own posts, with quotes like "you should not be doing that", or things like we should not be using the program for so and so things.
And I never said that those issues were not important. I said they are not related to our issue here, in the sense that we are asking for a specific feature. We are not asking for the same implementation on the backend that would create those other issues. We are asking for an organisation feature which the .unwanted folder unintentionally provided very well.
Regarding the libtorrent thing, that is the impression I got from one of the replies somewhere up there which I don't have time to look for, but it made it apparent that it was a libtorrent thing. In any case, that's for whoever is coding to really figure out as it'll be important for them to know rather than end users.
Lol, see what I mean? Just because YOU consider something ridiculous, doesn't mean it's ridiculous for everyone. Just enough now, your input is constantly "my way or the highway". Nobody is "spamming" the client. But many of us who archive things search for old/rare things that are often only available in torrent form now. Nobody is spamming them, but sometimes you find several magnets that are the same file but compiled by several different people, so hopefully one of them is more alive than the others. And this might be a shocker to you, but yes, some seeds actually do come back online after, another shocker, YEARS and the torrents do end up being complete despite being dead for any amount of time.
Lol, so now we are not using qB "logically". Why don't we rename qB to "mzsoB" at this point.
Ok, but removal of unchecked files is not the focus of this thread. The focus of this thread is to have a feature to move unchecked files into a subfolder. That's it. It's ridiculously clear, concise and ridiculously blown out of proportion at this point by needless discussion of removing unchecked files instead. The latter is a legit issue, but should be treated as separate so that the two don't end up destroying eachother and raising yet more tickets.
Yes, agreed, would be nice to have a feature that can be enabled or disabled to allow metadeta fetching in paused state as well. But as aforementioned, many seemingly dead torrents come back to life at some point in time, so what determines whether it's dead or not is the specific user's patience and allowance.
So again, I implore that we get back to what must have been repeated close to a hundred times now, which is to just have a feature to move unwanted files to a subfolder. Regarding deleting those files, yes, they should be deleted if the torrent is deleted as well, but the fact that the unwanted folder houses the unwanted files makes this an extremely trivial matter because at least you know what are the extra files and you can choose to leave them for the whole "partsfile" reasoning or remove them.
@sjlebl commented on GitHub (Feb 1, 2022):
I'm sorry, BUT I am not asking for a feature. I AM ASKING for a feature
that existed for YEARS, through at least 10 versions of Qbitorrent, TO BE
RESTORED. I don't BELIEVE unless someone explains it, that the feature
CAN"T be restored without bugs.
I also assume, until told otherwise, that it would be EASY to reactivate
the old code and feature, as I have not heard there was some HUGE rewrite
of the entire codebase.
If someone wants to explain to me why my assumptions are incorrect, that
would be great.
If someone wants to tell me I'm ranty and illogical because I want FEATURE
CONSISTENCY through updates, please just don't.
(They're FEATURES because they provide SOME functionality that you should
assume SOME of your 75 million users RELY ON. When you delete them or
change them substantially, for no COMPELLING REASON, you are being an
inconsiderate of the users programmer.)
Thanks.
Peace and warm regards,
Stephen LeBlanc
On Tue, Feb 1, 2022 at 3:51 AM am117 @.***> wrote:
@mzso commented on GitHub (Feb 2, 2022):
@BattouSaeen Alright then. Keep doing what you're doing the way you were doing, without taking any advice and keep ranting about it. It's a problem for you not me. If you're lucky some change will happen that relieves your problems. If not you can keep doing it for infinity and beyond.
@sjlebl You as well. Features change. You reiterating for the umpteenth time that it has existed for years won't change anything. I'm sure many other buggy features existed for a good while in QB, just like most long lived SW. (Writing every other word in your comments in capital won't make it acquire a good argument)
@sjlebl commented on GitHub (Feb 2, 2022):
@mzso
Are you in any way involved in the development of the SW, or are you just
spitballing at the moment? At an issue that you don't care about. Why?
Peace and warm regards,
Stephen LeBlanc
On Tue, Feb 1, 2022 at 11:40 PM mzso @.***> wrote:
@KayLeung commented on GitHub (Feb 2, 2022):
new V2 attracts me to make an upgrade in the future. (maybe 6 months or more later)
Since I have a bunch of web tools to manage my torrents. I look into API first.
I don't know others but the below code solves my problem. Nothing cool, just hook it into FilePriority settings and append
.unwantedto filename.This is only 5 mins test, use it at your own risk. but it passed my OWN tests.
(don't be picky on my quick code test :) I know it can be better)
github.com/qbittorrent/qBittorrent@facfa26eed/src/webui/www/private/scripts/prop-files.js (L312)if you want to test, just download it and set alternative webui. open WebUI to unselect things (only binding the checkboxes. dropdown doesn't work yet)
@sjlebl commented on GitHub (Feb 2, 2022):
Thank you.
I do not have the ability to compile into Windows executables. If you make
this work and are willing to share an .exe or, that would be great.
Peace and warm regards,
Stephen LeBlanc
On Wed, Feb 2, 2022 at 12:30 AM Kay.L @.***> wrote:
@TheArgentinian commented on GitHub (Feb 2, 2022):
I needed space so I just deleted 500mb worth of parts going back to 2019(!). I hope I didn't break anything.
@sjlebl commented on GitHub (Feb 2, 2022):
I was doing a Windows system update and rolled back to v4.2.5.
.unwanted folder is back!!!
SAVE to a different directory from different watched folder is back.!!!
qB loaded in less than 3 min with 9552 torrents.
I also was curious so I did some searching for the DREADED lost .parts
files. After 7 years of use, I have found (gasp) a total 0f 206 .parts
files, taking up a whopping 9.43 GB out of my 18 TB of storage. ONLY 1 file
is larger than .5 GB.
With 3 clicks, I deleted all the ones older than 8 months.
Cheers everyone. Thanks for the discussion.
On Wed, Feb 2, 2022 at 7:21 AM TheArgentinian @.***>
wrote:
@KayLeung commented on GitHub (Feb 3, 2022):
If you have NodeJS, this script will help you to clean up unselected & parts:
https://gist.github.com/KayLeung/9a2daa934d222c54889a6e2da7774091
this is a cut-down version from my private script. I will not spend too much time on it (, unless there're 30 or more people needed) but I welcome you to give feedback on gist above.
(I will not answer anything related to my script in this thread that makes noise for others. Thanks!)
@mzso commented on GitHub (Feb 3, 2022):
@sjlebl commented on 2022. febr. 2. 08:46 CET:
Forgive me for trying to give advice to people, who clearly only wanted to whine.
@BattouSaeen commented on GitHub (Feb 3, 2022):
@mzso
Thing is, you're not offering useful advice. People want to do X, you keep telling them to do Y instead, when Y is clearly not what they want nor asked for. Then you say they're whining. Many have given you feedback that they don't wish to do what you are suggesting. And most importantly, telling people they are using the software "illogically" and "that's unreasonable" etc. is not giving advice. It's projection of your own usecase onto others' and that makes no sense. If you think people wanting a feature is wrong and you have been against that from the beginning, then there is no advice, there is just needless back and forth, so save yourself your own time.
@sjlebl commented on GitHub (Feb 5, 2022):
Thanks Kay.L
I really appreciate it. For not 4.2.5 is working well, but I will save your
script.
Stephen L
On Thu, Feb 3, 2022 at 2:34 AM Kay.L @.***> wrote:
@simo1994 commented on GitHub (Apr 1, 2022):
@thalieht please elaborate on why you're removing the "confirmed bug" tag.
A good number of users is here precisely lamenting that dropping the "unwanted" feature creates buggy behavior.
I completely agree with @sjlebl that minor releases shouldn't break major feature consistencies. This change didn't alter an icon, it completely altered how users should manage their torrents, there should have been a serious and participated discussion before implementing it.
@thalieht commented on GitHub (Apr 2, 2022):
Because it's not a bug.
@porg commented on GitHub (Jul 23, 2022):
The home page and the wiki show nothing about how qbittorrent handles unselected files which are overlapped by a torrent piece of the previous and/or next neighbor. See:
This is a crucial differentiation factor when deciding the pros/cons between different BitTorrent softwares, which handle this BitTorrent architecture immanent issue with quite different strategies:
I'd appreciate a short and clear explanation in official documentation source in a normal language which explains to users how this aspect works in qbittorrent, and whether there are any user settings, which can influence that behavior, and also if the filesystem/OS makes a difference (unwanted files consuming the full file size, or only consuming the overlapping parts which sparse files support), and if qBittorrent has different handling of this per different filesystems/OSes. Thanks!
@charakaSamawry commented on GitHub (Aug 17, 2022):
mad .. usually have either wanted the entire torrent or downloading torrents with larger files; so hadnt noticed this issue.
As of late though, i have downloaded some torrents with smaller files and with files i knew i didnt want - magazine packs, and i only want a few of the magazines in the torrent, and matching cover images, approx. 100-200kb per image, meaning its parts encompass other files which end up being also completely downloaded. This means they dont get the .!qb extension and, being in the same folder, get mixed in with 'checked' files, in the torrent. It would be nice if they were separated from the checked files which are the things i actually wanted to download (As it seems used to be the way).
I think it would be best, and make the most sense, if, not only incomplete files, but also unwanted/unchecked files also receive the extension .!qb ... no?
It creates a myriad of issues already mentioned in this post - that i dont quite understand why/how some dont seem to see in their own use cases..
@Eniff commented on GitHub (Sep 26, 2022):
This is very bad for file management. Because of this reason I am returning to BiglyBT where at least I can set it up so unselected files are in a separate directory and deleteable with a press of a button. Very bad idea to remove this feature.
@BujiasBitwise commented on GitHub (Oct 10, 2022):
I want to inform the maintainers about some scenarios that were broken by the .unwanted feature, or by any renaming/moving of unselected files. If it gets reintroduced, it would be nice if you could override the default behavior on some torrents.
When adding a new torrent with similar data to what you already have, sometimes there is the need to unselect everything, recheck and start seeding without selecting anything (stealth seeding). Reasons:
You may not have the partial files to make them show as 100%, and your ratio in a tracker may not be enough to download those missing chunks.
It may take you some time to know which files should be selected (like when updating partial rom sets).
You may download some files from a seedbox to your computer, because you don't have enough local space or need more seedbox space. But you still want to keep seeding the other half of that big, popular torrent.
Problem 1
I don't know if files in .unwanted were seeded. If they were, this is not a problem.
Problem 2
You may still be using those unselected files, and moving/renaming them would break everything unless you hardlink/snapshot them first. For example, a torrent containing roms may be used by an emulator, or one containing media by a frontend. They may be part of an overlay fs or needed by rom management tools.
This also happens when using the suffix !qB. After pointing a new torrent to your old data and rechecking, the part file will be missing and many files will be less than 100%. So they'll get renamed to !qB and things that used the files will break. Fortunately, it can be disabled, although not only on specific torrents.
@BattouSaeen commented on GitHub (Oct 10, 2022):
@memstat don't worry mate, there hasn't been any indication of any intention to work on anything remotely close to the .unwanted folder in 2 years, so I don't think anything will happen. This feature request is probably ironically in a metaphoric .unwanted folder rofl. The only hope is if someone creates a fork which includes behaviour to move unselected files to a separate folder.
@glassez commented on GitHub (Oct 11, 2022):
@BattouSaeen
Everything is much simpler. There is no paid staff in the project. The project is maintained by enthusiasts in their free time, besides, we have only a couple of active contributors who are familiar enough with the app core to make acceptable changes there. So we cannot cover all aspects at once, we only give preference to the most important ones.
Hell, it was supposed to be just a hobby, but lately it seems that I work in this organization (only without receiving any salary).
As for ".unwanted folder" topic, I tend to believe that the whole problem exists due to the fact that libtorrent (and, accordingly, qBittorrent) does not allow you to really ignore some files from the torrent. Otherwise the very fact of managing unnecessary (aka unwanted) files looks meaningless for me.
@BattouSaeen commented on GitHub (Oct 11, 2022):
@glassez
I know, I appreciate it because I have a software dev background. I would not even have bothered making this thread if I could do it though, because unlike others, I lack the talent. Many times I thought about doing it but it's just too big for me to not end up breaking something, it's why only those who have an overall understanding of it can be the ones to do it in the best way.
As I've mentioned many times, it is not that we want the inefficiency of file parts in other files back. What we want is a simple move operation done. i.e. when a file is unselected in qB GUI, it creates a subfolder in which those unchecked files are moved. This is a purely organisational feature being asked for. It used to be the .unwanted folder behaviour, so that's what's being mentioned due to its familiarity. It may look meaningless to you because you personally did not find it useful, but for several of us on this thread, on reddit (where this thread is quoted I believe), it was very useful and that's why we are stuck on 4.2.5 all this time.
Edit: If you can tell me what to do, which files are relevant and how I should go about it, I will do it and I will even agree to compensation for your time and effort. What more can I offer? I know how to code a simple behaviour like this, but I do not have the knowledge of the overall project, the quirks, the stuff that is interconnected and has relationships that may break if I accidentally do something wrong. I don't have that and can't offer that, I don't have the experience. But I have basics of C++ and willingness to do it if guidance is provided.
@BujiasBitwise commented on GitHub (Oct 12, 2022):
@BattouSaeen it needs to be optional if it's reintroduced, or it will break the scenarios I described. I wasn't able to use this client until .unwanted was removed. I'm not sure if this would be easy if a lot of core things are touched. You don't want to keep 2 separate implementations of how pieces are found.
Workaround
A simple option "move unwanted files to x directory" could be a workaround. It assumes your torrent is paused and you don't want to do anything that makes the client freak out because some files are missing. This would mostly be a way to clean the files before removal. But people would expect it to behave properly when pausing and selecting, so this partial solution is better left as the external script posted in this thread.
If you want to keep seeding after the workaround, it's messy but you could unselect everything, recheck and start. That wouldn't seed the partial pieces of the files you moved though. If you select anything, https://github.com/qbittorrent/qBittorrent/issues/17509 will get triggered.
Implementations
@BattouSaeen commented on GitHub (Oct 12, 2022):
@memstat
Agreed, it would ideally be an optional feature. I believe I and a few did mention this earlier in this thread, whereby one can choose which behaviour is perfect for their usecase. Keeps everyone happy, has a slight increase in code, but such a small feature shouldn't be something too much and can be compartmentalised as much as possible to remain independent for the majority of future updates.
I won't pretend to fully understand the scenarios you listed due to general lack of experience, so I'll go by with what I partially understood.
The main objective of this thread is to bring back only this functionality -> unselected files should be moved into a subfolder within the torrent's own directory. The matter of cleaning files, like the script does I believe, is not part of this feature because it's an extra step and an extra objective. In my case, I only need the subfolder behaviour. I don't unselect files to ONLY remove them. I unselect for the utility of automatic movement and organisation. This opens up my options - it allows me to have the files neatly organised without having to go into the file explorer and do it manually. It also allows me to delete them later on IF I desire. But it's a perfect "stop-gap", "save spot", where you can decide what to do later on (perhaps with the script) or do nothing and just keep things organised. There are certain situations where this is handy,
for example:
You have a torrent with two audio clips in them. Say some ancient, rare audio. Both audio clips are the same topic, but:
File 1 = complete duration, bad quality
File 2 = incomplete duration, high quality
In this scenario, one would want to keep both files because both offer something the other does not. This is a SUPER SIMPLIFIED example, but it gets the point across - what if there are several files that are the same content but each offer something the other does not. The .unwanted folder allows one to quickly isolate files that you want to compare and even acts as a mental aid to keep track of what you were working on. Now imagine if there are several files and some of them are being downloaded, some are done, you accidentally unselect one, which the modern qB I believe just deletes them and so need to be redownloaded. With the .unwanted folder, you still had the file, it was just moved, so you could essentially keep moving it for your own organisational needs many times.
I realise that might look simplistic because I can't give a more complex example but they exist, which is why this topic exists. The simple functionality of just moving files into the folder was invaluable. It was like a blade. A blade is simple, no moving parts, nothing fancy like a trimming machine, but that simple nature of the blade allows you to shave, cut, slice many things - hair, fruit, rope, fabric, whatever; whereas a complicated trimming machine is only good for one thing.
So I suppose one solution from my simplistic understanding is to keep legacy code for parsing and checking and downloading files in chunks which allows the .unwanted subfolder behaviour. But I imagine that breaks many updates that have been made to other parts.
So how about there be logic which just scans the local directory to look for missing chunks? This is where my knowledge is very lacking because I see .parts files being used even now in 4.2.5 but it keeps chunks in adjacent files and the unwanted folder is there. So if I uncheck a file and it moves into unwanted and I delete the files, I just have to recheck the torrent. It will then redownload just portions of adjacent files and store them in the unwanted folder. I believe this is the reason unwanted was nuked because you always had these ghost files in unwanted.
Maybe each torrent can have a checkbox which tells qB which way to store the parts files for it? If a torrent is saved with this legacy behaviour, then qB knows how to scan for them. If the modern method is used, then it stores all the chunks in the parts files only, removing need for unwanted folder bugs.
Let me know where I'm incorrect and I'll rethink and reword it.
@BujiasBitwise commented on GitHub (Oct 13, 2022):
@BattouSaeen
I think the desire to move unselected files makes sense. Most people simply want to move the clutter out of sight, and I think that would be the main justification for this. However, if it has the side effect of enabling other exotic use cases, great then. This is the maintainer's decision, anyway, not mine.
Script
It's not for cleaning, not really. It's using the api to get a list of priority 0 files and do something to them. It currently adds an .unwanted suffix, but it could easily be modified to move them instead. The problem is that if you don't let qb know about that, bad things will happen. Files coming back from the dead https://github.com/qbittorrent/qBittorrent/issues/17509 or "I expected a file here" type of errors. Letting qb know... means going back to 4.2.5, which maintainers removed on purpose.
Technical history
As a reply to your technical comments, I'm going to summarize in a single post how I understand the evolution of the feature. It might be useful to people who enter the thread for the first time.
Before having part files, with .unwanted
part_file.c was created in 2014, and became part of libtorrent 1.1.0 in Apr 11 2016. I don't know which qb version was the first to use that libtorrent, so I went back to 2013 and tested qb v3.1.4. Before libtorrent implemented part files, clients needed to do it themselves. Data belonging to priority 0 files (that is, unselected), like data from shared pieces, was stored in sparse files inside .unwanted. If sparse files were not supported, the overhead to fill them with zeroes was big, and they used a lot of space for no reason. I have observed buggy behavior in both .unwanted and !qB suffix (incomplete files not having it).
With part files, still with .unwanted
At some point, qb started to use the libtorrent with support for the part file, but still moved unselected files to unwanted. Qb 4.2.5 works that way. That's why you see .parts and .unwanted. The data I mentioned is no longer stored in sparse files, it goes to .parts if the file doesn't already exist. A part file has a header and an array of pieces. An empty slot is assigned for every piece you want to store there, from different files.
When you select files, pieces get stored in the files themselves. You still need to write zeroes if sparse files are not supported, and they consume all the space. But at least you now want the file, which wasn't the case when qb created individual files before the introduction of the parts file by libtorrent. If data of a selected file was in the part file, it gets copied to the final file. If unselected, it won't get copied back to the parts file, so you are stuck with it. I think the slot where a piece was stored in the part file will get recycled after it's been fully written to the final files.
This does what you want. There is no need to discuss implementation details, it had already been done. But buggy and it was not optional.
With part files, .unwanted removed
qb dropped support for .unwanted after 4.2.5, in 4.3.0. As they've said, it was buggy and I suppose it was considered a relic from the past that nobody needed anymore. It was required back when partial pieces were stored in individual files, but now it was usually empty.
v2/hybrid torrents no longer require a part file, nor sparse files in .unwanted. Files aligned to piece boundaries. They would only be used when pieces with >0 priority are in a file with 0 priority, but that would be weird.
Making unselected files disappear automatically when unselecting them had already been discussed in libtorrent. I'm glad it wasn't implemented, because I'm not a fan of unexpectedly having files moved around when unselected, as you know. Fortunately, @arvidn is the owner of libtorrent and he's also posted in this thread most of the things I just said.
@KayLeung commented on GitHub (Oct 13, 2022):
IMO, 2 separate issues but qB developers see them as a single one. (?)
qB developers may think that's virtually deleted only, so that's meaningless. But for most users, it's useful.
Problem 1: .parts
With the latest stable version, if you UNSELECTED a file, I don't see how qB or libtorrent doing extra actions to clean up chunks. .parts only removed until you REMOVE the torrent from qB. (I wonder if qB developers missed this point)
In fact, I think this is unimportant to this issue (original requests). This original request is about UX more than technical. Even you removed the files and data still in .parts. It's UNIMPORTANT to this request.
Problem 2: File management: A feature to mark unselected files.
I can't make comments to OLD .unwanted (that may do extra actions than I expected)
Iibtorrent offered
renameAPI. What I see we can do:.!qB -> incompleted file
.!unselected -> unselected file
(If I'm correct, it's tracked by .fastresume)
Above two actions should be identical. (Once again, This is identical. Nope?) All remaining stuff is still handled by libtorrent itself.
@sjlebl commented on GitHub (Oct 13, 2022):
Okay,
I've BEEN a programmer. I've WORKED with over 100 programmers.
I UNDERSTAND the tendency of programmers to think in terms of backend
functionality OVER user functionality. I also UNDERSTAND the tendency of
programmers to think of their use of the program as reflective of TYPICAL
USERS. (Which it almost NEVER is.) I understand that THEREFORE their
yardstick regarding any user complaint about a removed feature is: You
don't need that feature. There is an easy workaround. Only uninformed users
would ever do what you have been doing for the past 10 years. NO ONE but
you cares about that feature. That feature is inconsistent with my NEW
VISION of how the program should work. Goodbye.
Well, in this case dozens of users motivated enough to use this forum have
complained. That means hundreds of users at least once used this feature or
would if in HAD REMAINED IN PLACE.
STEP. I. So, again, if I download 3 torrents I find labeled "Classic TV
that is in the public domain." and it turns out each torrent has 100 files,
but the torrents don't download metadata start for 5-10 minutes, so I sit
down an hour later and the computer and find EACH torrent has 25 different
series in 25 different folders for a total of 2 Terabytes of data and EVERY
file has begun downloading is fully allocated and downloaded 2% into media
files. I immediately uncheck every program I don't want, quicking
deselecting 80% of the total series. I then check out the series I do want
and find that 80% of those are seasons I already have and deselect those. I
know have 4% of the original 2T selected and downloading and I so far am
happy. My total USER TIME for doing all of these tasks is less then 5 mins..
Step II. I then go to my file indexing program (Everything.exe for
Windows). and search all files for ".unwanted" in their path. I select all
and immediately DELETE 96% of 2T of unwanted files. This take me 60 seconds
of user time.
I'm happy and DONE.
WITH THE CURRENT SYSTEM, there is NO DISTINCTION IN THE FILE SYSTEM that
allows me to do step II.
So AS A USER, I would like the PREVIOUSLY FULLY WORKING FUNCTION OF THE
.unwanted folder RESTORED.
I just did a search for loose .part files of my file system. There's 229
files with 6 GB of data. I DON'T CARE. They can stay on my 16T system
FOREVER. It's the 6T of formerly .unwanted files that I care about.
ALSO, with regard to CONFUSING the client, I don't really care if there is
a substantial delay regarding when the MOVE to .unwanted occurs. The
client AT SOME POINT "notices" that files have been unselected because it
STOPS DOWNLOADING to those files. So if the unchecked files need to stick
around for several hours or days, I don't care, as long as they eventually
make it to the .unwanted folder so I can delete them all with 1 search.
And if there is NO DISTINCTION at the file system level of the 5000
UNWANTED files of 1000 active torrents, I CAN'T USE THE NEW qbitorrent. I
do not want to spend hours going back and forth to make sure I individually
deleted every file that I unchecked.
Not ONE technical person have every addressed WHY this feature went away or
WHY it can't easily be restored from the PREEXISTING CODE.
PLEASE, PLEASE, PLEASE tell us.... OR, better yet, restore the feature
from the preexisting code.
OR, add SOME TAG that the file system can easily search on, like a .!un
file extension.
Thanks to every programmer who has ever worked on this software.
Stephen LeBlanc
On Thu, Oct 13, 2022 at 2:59 AM Kay.L @.***> wrote:
@mzso commented on GitHub (Oct 14, 2022):
@sjlebl
Actually, for the problem you described a far better solution would be to not start downloading torrents that were initially added without metadata. I see multiple ways of doing this:
(A useful auxiliary feature would be an "erase highlighted unselected files" feature, which would free up space, and not just with accidental downloads. It would of course keep the necessary first/last pieces as needed.)
@KayLeung commented on GitHub (Oct 14, 2022):
@mzso
I have no chance to look into it yet but the metadata download feature has been merged
https://github.com/qbittorrent/qBittorrent/issues/17792
https://github.com/qbittorrent/qBittorrent/pull/17814
But it isn't the answer for .unwanted.
@mzso commented on GitHub (Oct 14, 2022):
@KayLeung commented on 2022. okt. 14. 09:22 CEST:
Ah cool. So it's already implemented in a way. So I guess we can test it with the next version.
For a large (most?) part it seems like it is.
@tworepetae commented on GitHub (Nov 28, 2022):
How are those new additions a solution to the problem at hand?
Just to reiterate my typical workflow with qbt v4.2.5:
As far as I understand this is still impossible to pull neatly after 4.2.5, and that's why I still haven't upgraded. Correct me if I'm wrong.
@stduhpf commented on GitHub (May 8, 2023):
I just ran into that issue with a torrent with over 1000 files where I only wanted some of them, and the only simple solution to separate them was to downgrade to 4.2.5. If incomplete files can get the
.!qBextension, It must be possible to do something simillar with unwanted files, right? Even without reintroducing the.unwantedfolder exactly as it used to be...@ghost commented on GitHub (May 8, 2023):
That would make too much sense!
@BattouSaeen commented on GitHub (Oct 26, 2023):
I was going through commit #12820 and this seems like the relevant bit of code that was removed:
I know there are other places .unwanted appears in code but this seemed the most relevant bit. It seems straightforward and I don't see it interacting with parts files, at least in this snippet, directly. So can anyone explain what would break if this were reintroduced, altered and adjusted for the modern code structure? I would love to do it myself but considering how complicated it is and how difficult it is to understand what else is depending on this code, or what this code is affecting in other files, it's nearly impossible without going all the way back and spending years trying to understand how it all connects together.
@sjlebl commented on GitHub (Oct 27, 2023):
I have NEVER GOTTEN any response from any relevant programmer as to why
this was stopped. .parts files seem to barely be an issue, for me anyway.
If you implement and need an alpha tester in Windows, let me know.
Peace and warm regards,
Stephen LeBlanc
On Wed, Oct 25, 2023 at 10:50 PM am117 @.***> wrote:
@KayLeung commented on GitHub (Oct 27, 2023):
I believe it should call this API instead right?
github.com/qbittorrent/qBittorrent@35e4b35d12/src/base/bittorrent/sessionimpl.cpp (L4983)@see: https://libtorrent.org/reference-Torrent_Handle.html#move_storage()
Acutally, I can do it now with current qBitrroent's rename feature
If that's not a bug, I can't see any differences between "unselected" vs "rename + unselected"
@glassez commented on GitHub (Oct 27, 2023):
@sjlebl
It was deleted because there were a lot of complaints about its behavior and no one wanted to keep maintaining it.
Even now, when I clearly see that there are many users who want it back, because of the difference in their opinions about its appointment, I cannot form a clear idea about it. It is especially unclear to me how it could behave in extreme cases (especially considering the fact that
libtorrentdoes not provide advanced file renaming capabilities).I could bring this functionality back, but it would have pre-existing (or similar) drawbacks.
The task is further complicated by the fact that almost none of the users interested in some feature shows any participation in its development (by alpha testing).
@BattouSaeen commented on GitHub (Oct 27, 2023):
Hi @glassez , I think the general consensus amongst the differing opinions is that an unchecked file should be grouped somehow and the folder option seems best. It doesn't have to be exactly how it was in terms of code - you would know best what is the best refactoring or implementation for it, but as long as it separates the unchecked into a folder, that would be great. The folder allows to keep the directory fairly neat (versus the millions of partsfiles I remember popping up if hidden files viewable) and we can further use our own basic bash scripts to clean up for those who used this 'feature' for cleanup.
I'll be absolutely up for alpha testing. I have a clone of the repository but alas, I can't make up for all the experience required to make a real coding effort, in which case I would absolutely do that too (unless a tutorial pops up that clarifies how everything is connected).
@KayLeung where/when/for what feature does that renaming dialog appear?
@glassez commented on GitHub (Oct 27, 2023):
@BattouSaeen
As far as I remember there were separate .unwanted folder per torrent subfolder previously. Is it good to be recreated in the similar way? Or is it better to have single .unwanted folder for torrent (following torrent folder structure inside it)?
@escape0707 commented on GitHub (Oct 27, 2023):
I think for example, if I pointed qBT to download into
~/Downloads/BitTorrent, then as long as I don't have too many.partsfiles laying everywhere in that folder, it would be a lot better for going through the file list, especially when I have a lot of torrents downloaded to there.Maybe a
~/Downloads/BitTorrent/.qbt_partfilesthen organize part files inside that folder in any of the preferable ways?@glassez commented on GitHub (Oct 27, 2023):
One of such "extreme cases" is the file that exists on disk but unchecked when torrent is being added. To be consistent it should be moved to .unwanted folder as well.
@escape0707 commented on GitHub (Oct 27, 2023):
But current
.partsfiles logic didn't treat unchecked files like that, right? qBT doesn't merge those files back into the.partsfile.@glassez commented on GitHub (Oct 27, 2023):
@escape0707
IIRC, this Issue isn't about
.partfiles. Anywaylibtorrentdoesn't provide any way to control.partfiles, unless I'm wrong.@BattouSaeen commented on GitHub (Oct 27, 2023):
@glassez Yeah I think the original per-subfolder unwanted folder is best as that reflects the order of the torrent. Alternatively, there can be one .unwanted folder with subfolders created if the files unchecked were nested in subfolders. For example
-- file1
-- subfolder 1
--- subfolder file1
if I uncheck both file1 and subfolder file1, then if we have just one .unwanted folder for the torrent (and not per subfolder), then the .unwanted folder would be similarly structured:
-- .unwanted folder
--- file1
--- subfolder1
---- subfolder file1
I would personally prefer the original, .unwanted folder per subfolder, but if having one main .unwanted folder and keeping structure within it is easier/better, then I'm ok with that too.
@escape0707 commented on GitHub (Oct 27, 2023):
Okay, maybe this thread is too long and too old from the date I subscribed it. I kind of confused just before... Let me hide my comments to reduce the confusion.
@glassez commented on GitHub (Oct 27, 2023):
I don't think one of these options is easier than the other. You just need to choose one of them, which will eventually be implemented.
@BattouSaeen commented on GitHub (Oct 27, 2023):
@glassez in that case, the original per subfolder behaviour then, as that is what everyone is used to and has legacy code to guide/show how it was already implemented.
Edit: ideally, being able to choose these behaviours in the settings would be gold :D :D
@sjlebl commented on GitHub (Oct 27, 2023):
In terms of useability for MY needs, anything that allows me to DELETE all
.unwanted files in my system would work... a single .unwanted folder, many
.unwanted folders, OR a name tag like .!un.
What I do now with the old qbittorrent is occasionally I use an indexer,
such as Everything.exe, to search for all files with .unwanted in the
path, and mass delete them.
Thank you.
Peace and warm regards,
Stephen LeBlanc
On Fri, Oct 27, 2023 at 8:56 AM am117 @.***> wrote:
@glassez commented on GitHub (Oct 28, 2023):
Although, on closer inspection, a single
.unwantedfolder for a torrent may be easier to implement. Since you don't have strict preferences, I'll just choose something that seems more convenient for me to implement.@BattouSaeen commented on GitHub (Oct 28, 2023):
I had a further think on it and I think it's important to retain the original folder structure if there will be only one .unwanted folder. Because I remember there was a torrent I came across that had files with the same name in different folders. If you have only one .unwanted folder for the entire thing then there will be a clash of files if they have the same name (but they didn't clash during download because they were each in their own folders of differing names).
E.g.
-root
--folder1
---somefile1
-folder2
---somefile1
So it may actually be the case that having .unwanted folders per subfolder is the better way as you don't have to recreate the structure in a one big unwanted folder and not have to worry about renaming or anything because the unwanted file will be in its related folder already.
EDIT: Actually, I think the original way is the best way (unwanted per folder, per subfolder) because those of us still on 4.2.5, updating to 5.0 if it has .unwanted as it was, then it should be seamless and all files will be properly connected. If you change the behaviour and make it be only one .unwanted folder for an entire torrent, then old files downloaded during 4.2.5 will break connections. I highly highly suggest reimplementing the original way. Changing it will probably introduce all these new issues that can be avoided.
@glassez commented on GitHub (Oct 28, 2023):
Sorry, as I said above "I'll just choose something that seems more convenient for me to implement". Taking care of compatibility with such an outdated version is a lost cause.
In any case, you won't be able to upgrade from v4.2.x to the latest version without problems. To all those who want to do this, I strongly recommend that you keep a backup copy of all torrents (after disabling all options that affect the location and naming of files), do a clean installation and then re-add the necessary torrents.
@BattouSaeen commented on GitHub (Oct 28, 2023):
Why is it a lost cause? You mentioned this has nothing to do with partsfiles, so the only thing is that the program would need to be aware of and pointed to the correct files on disk. Since unwanted folders are per-subfolder, it would be a recursive operation to find and point the related files, right? Why would reimplementing the same behaviour seem less convenient than trying a potentially new thing that may introduce new issues? With the old way, the issues are thoroughly known.
Either way, what matters is that it be per-subfolder like before. I obviously am not saying it should be coded the same way as before because I imagine that's where the convenience part comes in. I dunno, I can only say that all of us here at least ask for the same functionality back - we'd rather have the same way something was done rather than experiment with something that potentially screws up existing files or worse still, makes many new unforeseen issues that someone else on the team can use as a reason to once again remove the entire feature. Hope that made sense.
@glassez commented on GitHub (Oct 29, 2023):
Is it unclear from my previous comment?
It's not about
.unwantedfolders. There are quite a lot of differences between these versions and we don't care about compatibility to such a depth. Even upgrading to the next version can cause compatibility issues, although we try to smooth them out.@BattouSaeen commented on GitHub (Oct 29, 2023):
Okay, I trust you will do your best to have the closest, most familiar solution implemented 😊
If you can perhaps indicate which files are most likely in play, I can take a look at the code again to try and get familiar. i.e. the old code that was removed was in session.cpp, so if one were to add it back there, what other files/modules are likely getting affected? Hopefully that made some sense, not quite sure how to word the question.
@sjlebl commented on GitHub (Oct 29, 2023):
Okay, I'm curious. I USED to be a programmer. Why is it impossible.
Unless the ENTIRE code was re-written, why can't the old code be
resurrected? What the new system does now when you click DO NOT DOWNLOAD is
to stop downloading the file and that's it. The file is preserved in the
download. It can be rechecked and restarted.
What it USED to do is 1. stop downloading, and 2. also move the file to an
.unwanted folder just below where the file is located. 3. Otherwise
preserve the file status so you can click Normal and move the file back to
its original folder.
I understand that a number of subroutines might be affected, but couldn't
you locate those by searching the code for v4.2.5?
Peace and warm regards,
Stephen LeBlanc
On Sun, Oct 29, 2023 at 12:42 AM am117 @.***> wrote:
@sjlebl commented on GitHub (Oct 30, 2023):
I'm happy to alpha test. I'm even happy to download a nightly or weekly or
whenever build on a different computer and run 100 torrents on it and test
it out for whatever behavior you implement.
I can even move multiple torrents to new folders and check that ..unwanted
moves as expected and delete files in .unwanted and see if recheck works
or if that breaks anything else.
The current behavior is leave the file on the disk and DO NOTHING. So, if I
download a torrent with 100 LARGE files, like 1 gig each, and realize after
10% I only want 10 of them, there is NOTHING I can do within qbitorrent NOW
to indicate the 90 files I don't want. I have to go to the file system and
pick out the files I don't want by hand.
So, ANYTHING seems better to me than that.
Whatever the complaints were, the current behavior seems MUCH WORSE. Even
deleting the DO NOT DOWNLOAD files immediately to the recycle bin would be
bettar than the LEAVE THEM IN THE FOLDER and don't DO ANYTHING to mark that
those files have been changed to DO NOT DOWNLOAD.
Thanks for considering fixing this. .If doing SOMETHING somehow causes
complaints for other users, I am happy right now to stick with v4.2.5
Peace and warm regards,
Stephen LeBlanc
On Fri, Oct 27, 2023 at 7:42 AM am117 @.***> wrote:
@glassez commented on GitHub (Oct 31, 2023):
".unwanted" folders are hidden on *nix due to their names. Previously qBittorrent set "hidden" attribute to these folders on Windows too. Is it really needed?
@glassez commented on GitHub (Oct 31, 2023):
#19842
Fortunately, it turned out to be not so difficult to implement it in a compatible way, so it creates ".unwanted" subfolders in each folder as before.
@sjlebl commented on GitHub (Oct 31, 2023):
I don't believe setting /.unwanted to hidden in Windows is important. Most
slightly sophisticated users chose to see hidden files in Windows anyway.
Also, leaving it unhidden makes more sense as the whole point of the folder
is to let users KNOW there are some DO NOT DOWNLOAD files in the folder.
When you said not so difficult to implement in a different way, does that
mean you've done it? Is there an ALPHA windows .exe or .zip file that I
should install on my test system?
Peace and warm regards,
Stephen LeBlanc
On Tue, Oct 31, 2023 at 10:15 AM Vladimir Golovnev @.***>
wrote:
@BattouSaeen commented on GitHub (Oct 31, 2023):
@glassez awesome! Thank you!
@sjlebl @glassez maybe it can just be in the options of qb to set the unwanted folder as hidden or not. After all, I believe there is just one line of code like what it was in an old commit
SetFileAttributes(parent_path.absolutePath().toLocal8Bit().data(), dwAttrs|FILE_ATTRIBUTE_HIDDEN);Could just be nested in a
switchor something.@glassez commented on GitHub (Nov 1, 2023):
I still decided to make it "hidden", as it was before.
You're trying to judge the iceberg again on his top. Do not forget that such option will require processing its switching from one state to another, i.e. if someone enables it, it should make hidden all ".unwanted " folders of all torrents, and vice versa. I don't want to deal with it now.
@glassez commented on GitHub (Nov 1, 2023):
Sure. I even gave you a link to the corresponding PR, didn't you notice it?
Test builds are available on GitHub Actions (as .zip and even as installer for Windows). Just choose appropriate PR you want to download build artifacts for.
@BattouSaeen commented on GitHub (Nov 1, 2023):
@glassez Good point; I don't fully grasp why it could not ignore .unwanted folder states of hidden or not hidden of existing torrents, but I trust you're right and either way, I prefer it hidden as was the case before and as you've decided now as well.
@sjlebl commented on GitHub (Nov 1, 2023):
Wow,
Vladimir, THANK YOU so much. I found the windows64 installer and after a
SEVERE Trojan virus warning from MS Defender which kept deleting the .exe
file, I forced it to ignore and installed successfully.
It launched wonderfully and I unchecked a few files in existing torrents
and it created .unwanted as expected, I could still run and rename the
files in .unwanted.
I moved the download location several times and the .unwanted folder
behaved correctly.
I started several NEW torrents and the behavior with DO NOT DOWNLOAD and
.unwanted was exactly as expected.
THANK YOU SO MUCH.
ONE ISSUE I HAVE HAD WITH THE PREVIOUS .unwanted BUILDS is that when I was
consolidating torrents that had the same files or for some reason had
copied a file with the exact same name into the main folder and then
unchecked the file in the .unwanted file, qbittorrent would delete the
completed file in the main folder FIRST and then overwrite the 0.1%
complete file from .unwanted to the main. Losing the complete file
forever. This is a different behavior from starting a NEW torrent or MOVING
a torrent with incomplete files, which EACH check if there are any existing
files with the exact name FIRST and THEN starts the torrent with the
pre-existing file restarted in the new torrent at 100% or whatever the
check finds. This is the only problematic issue I have had with .unwanted
and it is an unrecoverable error because the preexisting file is not moved
to recycle but is written over.
But thank you again so much. I will keep the new BUILD running on my 2d
system for a while and move it to my main system at some point.
Peace and warm regards,
Stephen LeBlanc
On Tue, Oct 31, 2023 at 10:57 PM am117 @.***> wrote:
@glassez commented on GitHub (Nov 2, 2023):
I mentioned above that it has many extreme cases that can be handled not in the way the users expect it.
Once #19842 is merged you could open corresponding Issues that describe such problems in details.
@glassez commented on GitHub (Nov 2, 2023):
Could you leave some comment in #19842 or at least put "thumb up"? This could help for other reviewers to understand that it is approved by affecting persons.
@sjlebl commented on GitHub (Nov 2, 2023):
I did. I am not super familiar with all github features.
On Wed, Nov 1, 2023 at 11:49 PM Vladimir Golovnev @.***>
wrote:
@mzso commented on GitHub (Nov 5, 2023):
I see no reason for the return of the problematic, glitchy .unwanted folders that sprouted all around the folder structure.
Though I see an advantage in removing deselected (usually incomplete) files and folders from the normal torrent content.
But it should be something better than unwanted was. At least folder that's only accessible to QB and at the torrent root, the same as the parts file. Or better yet, including the parts file. I imagine something like instead of a
<hashstring>.partsfile a<hashstring>folder, including everything (the parts file too) that's unwanted and don't belong to the torrent content.Some container file would be even better, but as I understand it can't be done by simply appending the varius files into a bigger file, without physically copying from one area of the storage to another due to lack of filesystem support, which sucks. As the libtorrent author explained, when I suggested unchecked files/folders should be merged into the parts file that already exists.
But I guess the former approach might bring up a variety of permission issues.
@sjlebl commented on GitHub (Nov 5, 2023):
"I see no reason for the return of the problematic, glitchy .unwanted
folders that sprouted all around the folder structure."
A whole bunch of users see A LOT of reasons. Please read the previous
posts. I have used the .unwanted folders feature close to EVERY DAY for at
least FIVE YEARS on Windows 10. I don't know about other OS, but I have
never had ONE GLITCH. The folders don't "sprout all around the structure."
They APPEAR only when needed, i.e. when you mark a NON-ZERO file to DO NOT
DOWNLOAD. They disappear when you RE-MARK all non-zero files as
downloadable.
They are EASILY DELETED IN BULK using any kind of indexer or command line
that can delete every folder named ".unwanted" Deleting the
".unwanted" folders IN BULK has NEVER caused me the slightest glitch in
Windows 10.
When this feature was deactivated a while back, there was NO WAY AT ALL to
determine FROM THE FOLDER STRUCTURE whether any particular file had been
marked DO NOT DOWNLOAD... AND there was NO WAY from qbitorrent to delete a
DO NOT DOWNLOAD file.
So, now that Vladimir has so graciously done the work to restore an
oft-requested feature, please only complain if it ACTUALLY affects you.
I have asked FOR THREE YEARS for people to give me ONE EXAMPLE where the
.unwanted caused EVEN ONE glitch. NO ONE ever has ... they just say,
vaguely, they don't kinda like it without EVER explaining, SPECIFICALLY,
why there was a problem with it.
TRUST US, the coders who ORIGINALLY YEARS AGO wrote the code enabling
.unwanted did so FOR A REASON THAT SEEMED GOOD TO THEM. The users who have
been BEGGING for return of this feature, likewise.
If it DOES NOT actually cause you a SPECIFIC PROBLEM that you can
SPECIFICALLY DESCRIBE with examples, please just thank Vladimir for
restoring it and move on to some issue that really affects your use of the
program.
If you can articulate a specific problem this feature causes you, with
examples, I would really be interested to hear it.
Thank you so much.
Peace and warm regards,
Stephen
On Sun, Nov 5, 2023 at 5:21 AM mzso @.***> wrote:
@BattouSaeen commented on GitHub (Nov 5, 2023):
@mzso we've been through this for years now. We finally had glassez very graciously implement it. If you don't want this behaviour, then open a new feature request and ask for the option to disable this, as was discussed briefly just a few posts ago above. That way you are positively asking for a feature without destroying someone else's needs. Don't ask to remove features that are useful to others, ask for the option to enable or disable one so that nobody is negatively affected.
@sjlebl how's your testing going? Have you tried a scenario where you upgrade with existing torrents from 4.2.5 to the new one? If so, did it work okay, were the old torrents relatively okay? And is there a way we can communicate directly to do some more testing/discussion together?
@mzso commented on GitHub (Nov 6, 2023):
@sjlebl All I see is a handful of loud people, with counter-intuitive habits. And if you didn't see glitches you're lying.
Then you weren't looking too attentively. And people are not in the habit of seeking out issues about getting features back that they're happy to have gotten rid of....
PS: Writing in capitals won't make your points valid. But it's rather obnoxious. Especially that you apparently didn't bother to read all of my comment.
@BattouSaeen I definitely don't want it back, as it was. I was expecting it would be behind a setting anyways, it would be a sad thing if it won't.
That feature was removed a good while ago, so nothing to ask for... And it was removed in the first place because people always complained about it.
It seems you guys only see what you want to argue about, and not for example, the suggestions I made.
@BattouSaeen commented on GitHub (Nov 6, 2023):
@mzso that's an incredible amount of projection and lack of reflection on your part. The dev who removed it is the exact same person who has now listened to us and implemented it back in probably in a much better way as well. I no longer have any idea what your problem is. You seem completely incapable of understanding that most people want this and find it useful (how about you just google the unwanted folder and see how many there are that wanted this back and linked to this thread). Kindly open your own issue and let your thoughts be known there.
@mzso commented on GitHub (Nov 6, 2023):
@BattouSaeen
Don't make up things. Most people definitely don't. Only ever a few wanted it back. Only a few ever spoke up. Mind you only three people even upvoted the OP.
I assume you had a mirror in front of you when you wrote this.
@glassez
Will there be a setting to enable/disable this? Particularly I'm hoping it's opt-in.
I don't want these very ironically named "unwanted" folders many places within the torrent's folder. Which definitely will be the case if the feature wasn't changed. Were there any changes to how it worked before it was removed?
@BattouSaeen commented on GitHub (Nov 6, 2023):
@mzso I am the OP. Since you can't make the connection between how many people have asked for it in this post + as I mentioned already, other forums like reddit and qb forums, there's no hope to get this through to you. You keep spamming this thread.
No, I don't look into a mirror while writing on github, maybe you do, which is why you can't see anybody else's use cases for features except your own.
Glassez has already explained how a setting to enable or disable this will affect things. You clearly haven't read even the last few posts explaining how he has implemented the feature again. Again, open a feature request for what you want and stop attacking us here. It's ridiculous.
@mzso commented on GitHub (Nov 6, 2023):
@BattouSaeen Sorry to interrupt your crying for and gushing about this buggy feature with some suggestions for improvement. And criticizing a willy-nilly reintroduction of this feature, that caused so many issues. And your references to imaginary "most people".
And by the way I don't see it mentioned whether it will be optional or not?
@glassez
But I'd rather not have this feature back as it was. So I'm arguing for it to be behind a setting, at the least. A whole lot of issues were closed when the feature was rightly excised, so those are now hidden. I alone filed at least two: #2798, #7966, and probably commented on others.
I think it really shouldn't be added back without some improvements in any case. Particularly the torrent being spammed with empty .unwanted folders, and such. So as I started to say before being buried by spam advocacy:
I think the deselected files should definitely not be inside torrent folder, it should be at the torrent root level, with the torrent folder structure mirrored inside. Which besides getting rid of junk would also help slightly with partial/undesired files being read by apps.
But the latter issue still remains if you load the torrent's root folder recursively, which is a common use case. To prevent junk being loaded, it should have restricted permissions to only allow access to QB. Since QB is only meant to access this content anyway.
To further prevent useless files (for the user) both unwanted files and the parts file can be in this folder. This why I suggested the "hashstring" folder instead of unwanted. To keep all the stuff that's not torrent content in one place.
Also, on a related note, it would be nice if we could simply remove unselected files within QB with or without .unwanted, I filed #9923 for this, which was erroneously closed when .unwanted was removed. Even though the issue doesn't depend on it.
PS: Will all the many issues filed for ".unwanted" will be reopened?
@BattouSaeen commented on GitHub (Nov 6, 2023):
@mzso you haven't bothered reading through AT ALL.
FIVE DAYS AGO: Glassez and I quote: "Do not forget that such option will require processing its switching from one state to another, i.e. if someone enables it, it should make hidden all ".unwanted " folders of all torrents, and vice versa. I don't want to deal with it now."
Literally after that, Stephen tested it out and he had absolutely no such issues you keep complaining about. No random empty unwanted folders. In fact, I am on 4.2.5, your supposedly buggy one, and I have NO empty unwanted folders. The only time you will get empty folders is when you keep going back and forth between wanting a file or not wanting a file.
Mods, @glassez sorry to tag you but can any of you please help us here? This feature has been asked for, we are grateful that you have reimplemented it and now it's closed. In three years, this user has consistently talked about "THIS IS BEST FOR ALL USERS" and it only talks about his own requirement, while he completely ignores what said users ACTUALLY keep saying they want, which was to move unchecked files into a subfolder. THAT'S IT. You keep saying "this should not be accessible to users" and "this is best for users" while we are saying NO, we WANT to access those files, we DON'T want them "resitricted to QB" and we most certainly do not want to just delete files that we uncheck. STOP spamming this thread. Open a feature request for an option to enable or disable this feature and leave this alone.
@mzso commented on GitHub (Nov 6, 2023):
@BattouSaeen That's about the hidden attribute though. Which is beside the point.
Also, remember this is an issue ticket a not an ".unwanted" fans group. Also you don't get to speak your opinion and claim it as an arbitrarily large people's opinion. Also don't misquote me.
It's pointles to argue with you you're only capable of bias and advocacy. Let's se what devs think.
@BattouSaeen commented on GitHub (Nov 6, 2023):
@mzso lol again you can't seem to follow. If you read above you will notice I am asking glassez about making the unwanted behaviour optional and I extended it to it being hidden or not. I have talked about it being optional THROUGHOUT this thread spanning 3 years. So once again, we can see who is the one trying to impose and misconstrue and misquote.
My "claim" is supported by the fact that there are years' worth of threads all over the internet linking directly to this thread and the fact that a dev acknowledged it and implemented it. For the love of God now, open your own feature request thread and leave this thread alone. Enough is enough. There is no debate because you are here trying to tell people what they want when we are telling you the exact opposite ... FOR THREE YEARS!!!
The devs have already told us what they think. This one was doable because it was already there before and has value for many users. Here's a quote from glassez when I revived the discussion and after this we decided how it should be and it was done, closed, FINISHED: "... Even now, when I clearly see that there are many users who want it back ... "
Going through the thread it is LITTERED with you arguing trying to convince the majority of us what we want when we have told you over and over again to STOP it and open your own feature request. It's unbelievable how you cannot leave this thread alone.
Your solution to removing unwanted folders is simple. A one-line batch script that will recursively go through your directories and deletes all the unwanted folders. Easy and simple. Someone even provided this in this thread if you search for it. Otherwise, clone it, figure out how to implement the option as you want it because this is very complicated code, very large code files and doing something in the options will affect several existing torrents in unforeseen ways.
@glassez commented on GitHub (Nov 6, 2023):
Let's not start holy wars. I'll just make ".unwanted" folders optional (fortunately, it's much easier than the case mentioned above with optional folder hiding), and let everyone stay with their opinion.