Could not create download: Bad torrent file, "name" is an invalid path name.

[skyegecko]

Hi,

I'm having an issue with a particular torrent file from Humble Bundle, which throws this error when I attempt to add it to rtorrent. It seems this is specifically caused by the way HB creates their torrent files, but that their method isn't necessarily incorrect.

There is a discussion about this format on the transmission bugtracker: transmission/transmission#294

Output from lstor:

lstor --raw -V tacoma-windows-64_05092018.zip.torrent
WARNING:pyrocore.scripts.lstor.MetafileLister:Found 0 candidate versions
WARNING:pyrocore.scripts.lstor.MetafileLister:Software version cannot be determined!
WARNING:pyrocore.scripts.lstor.MetafileLister:tacoma-windows-64_05092018.zip.torrent: name fullbright/tacoma-windows-64_05092018.zip disallowed for security reasons
{'announce': 'http://tracker.humblebundle.com:2710/announce',
 'info': {'length': 2782854494,
          'name': 'fullbright/tacoma-windows-64_05092018.zip',
          'piece length': 262144,
          'pieces': '<10616 piece hashes>',
          'private': 1},
 'url-list': [u'http://files.humblebundle.com/**********/tacoma-windows-64_05092018.zip?key=*******&ttl=**********&t=********************************']}
INFO:pyrocore.scripts.lstor.MetafileLister:Total time: 0.005 seconds.

The key part seems to be that rather than splitting the info struct into multiple file structs, the info struct contains a single file description, which in turn includes a directory path.

The consensus at the linked issue seems to be that this does conform to the torrent spec, but I don't have any knowledge on that front so won't comment.

The problematic torrent file can be made available on request (the game is currently free, so you can get a download link yourself if you want).

[pyroscope]

If someone wants to have a single file in a folder, they have to create a "multi"-file metafile with just one entry in info.files. The above is just garbage.

[skyegecko]

The above is just garbage.

That's certainly a valid interpretation. The spec is rather succinct on this point though:

The name key maps to a UTF-8 encoded string which is the suggested name to save the file (or directory) as. It is purely advisory.

You could argue this a whole bunch of ways:

• A directory is a file and a file is a file therefore this should be a multi-file block
• A / is an invalid filename character on pretty much every filesystem
• info.name should contain the name of a file, by including the name of a directory this is breaking spec

But going the other way:

• info.name could contain (other) characters that are illegal on some filesystem and these must be dealt with (a big deal for windows clients)
• info.name is merely meant to be a suggestion so can be ignored entirely if desired

It's worth noting that some clients can deal with these files just fine, otherwise HB wouldn't be distributing them like this for years. Not to mention whatever tool has produced this file.

If I can raise an opinion, having read a little about this now, it would be that the bittorrent spec should be interpreted as platform agnostic and that it makes no assumptions about filesystem compatibility with particular filenames. A rather catch-all solution would be not to reject names with "invalid" characters, since this set of characters is specific to the platform, but instead to convert them to safe characters. A / can be placed in this set of characters to be converted.

[pyroscope]

If you want evidence beyond the spec, the original BT client has validation checks that reject / in name.

[skyegecko]

I think that's fair evidence. I'm going to contact HB support and link this discussion.