Upgrade to 1.3.7 in Windows corrupted some torrents

[TheShanMan]

I upgraded and 2 of my torrents became corrupted. In each case, it caused a subdirectory called "_" to be created and expected the torrent's file to be located there, thus it put the torrent into download mode when the file was already downloaded to the root directory for the torrent.

I tried removing and then reimporting the torrent but that didn't help. But once I downgraded back to 1.3.6, removing and reimporting it worked.

Furthermore, half of my torrents are now being rechecked. Unfortunately with the volume of torrents I have, that's going to mean tying my system up with rechecking for quite a few hours.

[Cas]

I included the latest libtorrent (0.16.16) with 1.3.7 so this will likely be the reason for your issue, could you PM me an example torrent. It should be said this has not happened with other users upgrading to 0.16 so this is quite odd.

[zoom]

I'm also having issues with 1.3.7 on Windows. Some of my torrents started to recheck for no good reason and 3 of them can't recheck successfully; they stop at some percentage (always the same for each torrent) and the torrent state changes to "Error". Attempted to remove and re-add those torrents, but that didn't help. Rolled back to 1.3.6 and everything is working fine.
If this ends up unrelated to the OP's problem, I apologize for the thread hijack. Unfortunately I cannot provide a sample torrent because those with errors were from private trackers.

[Cas]

Ok thanks TheShanMan, there is an issue in 0.16.16 which was not present in 0.16.10, I shall pull these installers and try and resolve this with libtorrent dev.

[hyd]

Fundamentally, the .torrent file is invalid. Cas forwarded one of the torrents that's causing this issue.

Here's what's happening:

The .torrent file has a file in it that's in a directory with an empty name. No mainstream filesystem supports directories with empty names. Some collapse them silently into nothing and some don't. Specifically, windows' UNC paths don't allow it.

The change in libtorrent was to, from accidentally creating invalid paths like: "a\b\\c" which would be collapsed into "a\b\c", actually do something about directories with empty file names. libtorrent uses the underscore character to replace invalid unicode characers already, so it seemed like a reasonable character to use to repair invalid directory names too. While also adding support for stripping trailing white space and trailing dots in file names (which isn't allowed on windows), path elements could end up becoming empty even though they didn't start out empty. Like "..." for instance. repairing broken directory elements is an important security feature, to not leave room for loosely and arbitrarily defined behavior of edge cases. Even though I recognize it's inconvenient for libtorrent to change its behavior, I feel like this is an important enough edge case to handle deliberately rather than leaving it to chance.

I believe most blame should be directed towards the person creating the torrent (or perhaps the software used to create it).

[TheShanMan]

Great explanation, and I appreciate the time spent looking into this, Cas and hyd. I'll create the "_" directory, move the file into there, and upgrade. Sounds like that should prevent any attempt to re-download.

What's the deal with half of my torrents rechecking after upgrade? Is there some way I can prevent that from happening again when I upgrade back to 1.3.7?

[Cas]

I am not sure but it can happen with upgrading from 0.15 to 0.16 libtorrent. There is not much that can be done to remedy this as libtorrent needs the data verified.

[TheShanMan]

I upgraded and tweaked the storage of these torrents to use the "_", and that worked great.

However, the "Files" tab doesn't reflect the actual structure of the torrent. It doesn't show a "_" subdirectory. Bug? Will this be fixed?

[Cas]

It showed an "_" subdir when I tested the torrent, possibly if it's already added that's why? Not sure it's worth fixing, if you rename the file it might update with the correct path.

[TheShanMan]

Looks like you're right. If I re-add, it fixes the Files tab. It's a shame that it isn't a true reflection of what the torrent engine is doing, but probably not a huge issue, particularly since it's only an upgrade issue.

I'm not sure, but renaming either fixes the "corrupt" torrent or temporarily masks the problem. When I renamed it, because the Files tab was wrong (no "_" directory), it actually moved the file to the root directory. Force recheck now works with the file at the root directory. So the question is, whenever libtorrent gets upgraded again, is it going to reinsert the "_" directory (i.e. is the torrent file still corrupt) or will it be happy? I'm guessing the former. I see that I can also drag and drop the file from the "_" directory to the root directory and that fixes things as well.

It still seems to me there is something worth fixing here though because the fact that the Files tab can be out of sync with the actual torrent seems a little unsavory. Would it be reasonable for a Force Recheck to also recheck and correct what the Files tab is reporting? That seems pretty logical to me and would make me feel quite a bit better about the fact that the Files tab can be wrong. Perhaps that's a little more appealing to you than trying to fix it as an upgrade issue?