Remove .unwanted functionality

[sledgehammer_999]

Do you want to remove the .unwanted folder and just dump the unwanted files in the same dir as the wanted ones, like most bt clients do?

[dinjo]

Yes thats the way it should have been

[Ghst]

Yes, please. It's kinda annoying, since when you delete torrent and files downloaded from the disk, .unwanted folder remains on the disk.

[tekko]

Unwanted files in the same dir seems to be a better idea. When you checked/unchecked the files, sometimes they weren't moved or get duplicated... if I recalled correctly.

But can you keep those unwanted files hidden? otherwise, that could be confusing also... When you check those files again, just unhide them.

Thanks.

[zeomal]

I go with removing the .unwanted functionality. It can cause unnecessary complications.

[Dayman]

Dumping whole files you don't need into the same dir as needed ones is kinda confusing especially when you have a folder with multiple videos - there's no way of telling which one is complete w/o looking into qBt client.

I would personally go with ut-style single-file for mapping unused chunks and still use unwanted folder for files, already created/partially downloaded.

[loki]

Complete files don't contain .!qB (if you use this feature).

[zeomal]

So, is the .unwanted functionality going to be removed soon?

[UsL]

I hope not. I like the .unwanted function  : )  I sometimes collapse my DIR tree and seeing what is in the .unwanted dir makes for good visibility.

[joopbraak]

But then just completely remove the .unwanted functionality. I don't understand it's function anyway.
Why is it downloading files when I said I don't want them? It uses unwanted bandwidth and diskspace.
It becomes even more annoying when I don't have enough diskspace for the whole torrent, select only the files I want and still run into diskspace problems.

[ciaobaby]

Why is it downloading files when I said I don't want them? It uses unwanted bandwidth and diskspace.

Because the BitTorrent protocol does not understand "files" and 'folders'.

The payload is simply a block of binary data split into equal sized pieces, and some of these pieces may contain part of one file, all of one, or parts of several  'files' that are in the payload. These are known as "cross file pieces" and when ALL the pieces including the pieces that contain a part of a 'wanted' file are downloaded and reassembled in the correct order, the underlying disk filing system can recognise and access the now contiguous block of data as 'files' or 'folders'.

https://wiki.theory.org/BitTorrentSpecification

[Nemo]

I personally don't care where it is or even if its there or not, if it downloads the way it should then its all good for me.

As ciao says sometimes other ''parts'' are also needed to complete your selected file cause its divided into pieces thats why it needs to download the other files too partially (and taking space cause of this).

[Katzius]

Can I add a suggestion here?

Why not add a stop function in a form of a button which will cause you to stop seeding the torrent so then the client can delete the .unwated folder safetly without effecting the integrity of the file shared, which of course wouldn't matter much at this point because you essentially stop sharing it...
I might by wrong though.

I mean I like keep an eye on all of my downloaded torrents in the software it self and not in Explorer.
I really don't like going one by one and deleting the unwated folders.

[ciaobaby]

Why not add a stop function in a form of a button which will cause you to stop seeding the torrent so then the client can delete the .unwated folder safetly without effecting the integrity of the file shared, which of course wouldn't matter much at this point because you essentially stop sharing it..

There already is. It's the one on the toolbar with a red 'X'!

[AsaRossoff]

Not sure if an implementation decision was made on this; but I would advocate for a single piecefile (in same directory as torrent).
Bonus points if it's in uT format for clean import for converts, but that's not the primary value.

The primary values are avoiding user confusion about the "unwanted" files, avoiding confusion about if they have those files in entirety or not, and avoiding issues extra space consumption -- which may be significant -- on file systems that don't support sparse files or on file systems that do but files have been moved in a fashion that makes the files become solid instead of sparse (e.g. standard methods of moving between volumes, at least on Windows).  Plus even if users known that those files are "unwanted" files, they are still clutter.
thanks!

edit: The piecefile should have a name unique to that torrent, as multiple torrents may be stored in the same folder.  I think in one place in qBT (probably adding a torrent) the code disallows putting a multifile torrent in the same folder (both have same save location and parent folder name) as another, but does allow it everywhere else (umm, namely Set Location I guess).  The other client I have experience with (uT) allows it across the board.
I do this myself even in qBT and it allows for numerous optimizations (e.g. sometimes different torrents contains some of the same identical files, or a user may just want to organize the files together because they are related), and nothing goes wrong even with later moving one/some torrents from a shared location in qBT that a user can't take responsibility for (e.g. if the files themselves are shared between torrents, the user should copy, hardlink, or symlink them.)