uTorrent Checking hash of things that shouldn't

[SonicSam]

So

All my downloads go into C:/Downloads

I use WebUI for most of my stuff (via ?action=add-url...etc)

I have 2 torrents

Torrent#1: Tree

Tree is downloaded as follows

C:/Downloads/Tree/<files>

Now Torrent#2 comes in: TreePack

Now inside TreePack there is the same release as Torrent#1.

So normally it'd be

TreePack/Tree

TreePack/Tree2

TreePack/Tree3

Now, for some reason it detects C:/Downloads/Tree when that pack is added, and it starts hash checking, screwing everything up :<

Everything inside TreePack is now downloaded into C:/Downloads/, which causes the hash check on Tree.

Just try it out for yourself, it's occured a few times for me and the latest time a few minutes ago.

[jewelisheaven]

Version of uT?

[SonicSam]

1.8.2 Build 14458

[Ultima]

Legitimate and confirmed bug report. It seems that for multi-file torrents, µTorrent doesn't automatically append the torrent name to the default directory path if the "Add New Torrent" dialog isn't shown. Consequently, all files in the torrent get dumped into the default download directory instead of a dedicated subdirectory for that torrent in the default download directory.

That means it can potentially affect any torrent adding action that doesn't prompt the user with the "Add New Torrent" dialog, including (but not necessarily limited to):

- Adding a torrent while "Always show dialog on manual add" is disabled

- RSS downloads

- /gui/?action=add-file

- /gui/?action=add-url

- Magnet URIs

[jewelisheaven]

I thought it was reported fixed a while ago but the closest I could come was torrents

- Fix: Logic error where it would not copy the .torrent to the storage path if only part of the path was matched

- Fix: Bug where BT backend didn't take into account alt .torrent storage path

Since data being put into PATHNOTWHATIWANT\ instead of PATH\ thank you for the descriptive writeup.

[SonicSam]

Glad to help

Thank you for figuring out what I was trying to explain, haha .

[Ultima]

So scratch my previous assessment of the issue. It seems the problem is a bit deeper than I expected, and has a rationale behind it.

µTorrent is able to resume torrent downloads from existing data, even when a torrent is newly added. To do this, µTorrent has to check existing data in the directory it's being told to download to. Now, the thing is, when µTorrent is told "download to this directory," it's not sure whether you mean "download the data to this directory," or "use this directory to store the data's subdirectory." As such, the first thing it assumes is that you mean the former, and checks the specified directory for any potential existing files -- meaning at least one file with the same subpath\name and size as seen in the torrent job. If it sees one, it says "okay, we have existing data, so let's resume from this directory." If it doesn't find any such matching criteria, it simply appends the torrent name to the path and downloads fresh.

The reason I thought the problem was related to the Add New Torrent dialog is because the Add New Torrent dialog does not have this ambiguous case. The dialog has a "Save As" path shown, and whatever is shown there is the destination directory; µTorrent doesn't have to guess.

[SonicSam]

Hm, is that better or worse, is it still something that can still be fixed?

[Ultima]

It's not a matter of better or worse -- it's a matter of functionality, really. Can it be fixed? Perhaps. Haven't given it much thought, though I have reported it to a dev already.