Already existing files moved to .unwanted. And then erased erroneoulsy...

[mzso]

Hello!

I downloaded a torrent with only one file selected out of several 800-900MB files.
I already had two files of probably the same torrent from earlier.
They ended up being moved to the .unwanted folder. Which is undesirable in my opinion. Also confusing because it thought they were created pointlessly.

But it's even weirder that I got two more files that show up as 1.5MB (which is expected) and ~850MB in file managers (explorer, total commander).
The windows file properties window shows a similar disc size for the small file, but the big file shows up as 128 KB. Which is really misleading and confusing. I don't see a point for this.

Edit:
So I removed the torrent. Didn't check "also remove files" or whatever.
The old files previously moved .unwanted were deleted. Ouch...

[chrishirst]

Simple fix.

Do NOT check files as "Not Downloaded" and the problem will not happen.

Also read up on how the Bittorrent protocol actually works, and what cross file pieces are.

[mzso]

Hi!
I wouldn't call that a fix, but a rather inconvenient workaround.
You may need to carefully search for and select several files, and if you miss one it gets erased.

I'm aware of cross file pieces. It doesn't necessitate/validate a file that falsely appears to be full downloaded size.

[sledgehammer999]

.unwanted folder functionality is planned to be removed: http://qbforums.shiki.hu/index.php/topic,2294.0.html
However, I don't know if I'll make it for v3.2.0
When deleting a torrent qbt will remove files in the .unwanted folder because those are marked as "Do not download" in the program.
IMO, this cannot be fixed until the .unwanted folder functionality is removed.

[mzso]

@sledgehammer999 commented on 2015. márc. 29. 18:35 CEST:

.unwanted folder functionality is planned to be removed: http://qbforums.shiki.hu/index.php/topic,2294.0.html

However, I don't know if I'll make it for v3.2.0

When deleting a torrent qbt will remove files in the .unwanted folder because those are marked as "Do not download" in the program.

IMO, this cannot be fixed until the .unwanted folder functionality is removed.

That's great.
Although it doesn't seem to address the deleting already present files issue.
Nor the weird bogus filesize thing. (I know the file wasn't compressed because those are files are shown with a different color.)

[sledgehammer999]

Nor the weird bogus filesize thing

Those are sparse files. They signal the OS that they eventually will be X size but for now they just have less than X size.

Although it doesn't seem to address the deleting already present files issue.

The current functionality doesn't allow for a fix. Unmarked files are moved into the .unwanted folder. qbt cannot differentiate on pre-existing files and files written by qbt because the file user had initially selected the file and then unselected it.

[mzso]

@sledgehammer999 commented on 2015. márc. 29. 18:50 CEST:

Nor the weird bogus filesize thing

Those are sparse files. They signal the OS that they eventually will be X size but for now they just have less than X size.

Hmm... But what point is there for it to be used on a chunk that won't increase at all.
And why one chunk and not the other?

The current functionality doesn't allow for a fix. Unmarked files are moved into the .unwanted folder. qbt cannot differentiate on pre-existing files and files written by qbt because the file user had initially selected the file and then unselected it.

Well, it could leave these two where they are at least.

[sledgehammer999]

Well, it could leave these two where they are at least.

Let me rephrase my quote:

qbt cannot differentiate between pre-existing files and files written by qbt because the file user had initially selected the file and then unselected it.

.

But what point is there for it to be used on a chunk that won't increase at all.

That file is probably part of a piece(bittorrent term) that belongs to 2 files.
Read what chrishirst linked(here is the correct url): http://qbforums.shiki.hu/index.php/topic,2481.msg11814.html#msg11814

[mzso]

@sledgehammer999 commented on 2015. márc. 29. 19:33 CEST:

Let me rephrase my quote:

qbt cannot differentiate between pre-existing files and files written by qbt because the file user had initially selected the file and then unselected it.

I understand. It could still chose to not delete them when I remove the torrent from qbt.

But what point is there for it to be used on a chunk that won't increase at all.

That file is probably part of a piece(bittorrent term) that belongs to 2 files.

Read what chrishirst linked(here is the correct url): http://qbforums.shiki.hu/index.php/topic,2481.msg11814.html#msg11814

I understand this too. But one of them had a normal filesize (1.5MB) the other appeared to be 850 because it was a sparse file for some reason, no idea why.

[chrishirst]

It could still chose to not delete them when I remove the torrent from qbt.

How?

[mzso]

@chrishirst commented on 2015. márc. 30. 11:29 CEST:

It could still chose to not delete them when I remove the torrent from qbt.

How?

What do you mean how? By leaving them where they are.

[chrishirst]

But how can it know what you have unchecked them because you do not want the files and what you have unchecked because you no longer want the files??

Unchecked is unchecked to the client, it cannot know what your intent is when you uncheck them. Mind reading computers are still in the realms of science fiction.

[mzso]

Trolling much?

@chrishirst commented on 2015. márc. 30. 13:33 CEST:

But how can it know what you have unchecked them because you do not want the files and what you have unchecked because you no longer want the files??

This is not even the issue... The issue is that I already have those files

Unchecked is unchecked to the client, it cannot know what your intent is when you uncheck them.

Seriously. If you don't even understand the issue, why spam? This has nothing to do with the fact why you unchecked a file.

Mind reading computers are still in the realms of science fiction.

No-one expected that. The client could leave files that were created by whoever.

[sledgehammer999]

The client could leave files that were created by whoever.

This is what I am trying to tell you. Once you enter that save path all bets are off. qbt has the behavior of "files the user hasn't checked go into .unwanted." So at a later stage, eg you mark/umarked a totally unrelated file from the torrent after you have added it, it tells itself "hmm what are the unchecked files? -> this list. Do they exist in the save path? ->yes. Move them into the unwated folder".

It may be possible with many checks and guards in the algorithm to eventually achieve what you're saying but I am not going to bother. If I bother with unwanted it will be because I started removing the feature.

[mzso]

Okay, then it's settled. I don't like .unwanted anyway.
This with the sort of chunkfile that will come with libtorrent you mentioned will be a fine improvement.

[mzso]

I tried 3.4.0 and I still see an unwanted folder. (and remembered this discussion) So was it's removal abandoned? Or am I missing something.
I'm planning on moving from utorrent, but the .unwanted feature causing data-loss is rather painful. (The phony file sizes don't help either)

[mzso]

I've been thinking about this. I think it would be best to keep all pieces in a separate location, such as "BT_backup" (as .pieces or such) where the added torrents are stored anyway or a dedicated folder which can be changed independently.

Reasoning:

• The pieces don't belong in the download folder, they're not part of the download, only unusable pieces
• The pieces (no matter in what format) can only cause trouble, and making them hidden only makes things worse. For example when a user copies the folder, or archives it, or creates another torrent from it (etc) before removing it from QBT the user will accidentally/unknowingly copy/archive/create-torrent from the useless chunk files. It's just as bad if a program attempts to use (read write) a piece file, because it can't know it's a partial download. (provided the files are not renamed)
• It'll prevent accidental removal of piece files. A suspicious user might just remove the piece file because they don't know how it got there or what it its.