WEB UI error: The file has to be a torrent file

[kuzma]

Some tracker uses torrent file names with no extensions, just a names.

Adding such a file in the WEB UI causes the error:

"The file has to be a torrent file".

Renaming the file to the .torrent solves the problem.

The standard uTorrent interface has a feature (actually, windows has) to select the application

to open such a file.

Is there any option to configure the WEB UI to use the torrent file as-it-is with no checking the file extension?

[Ultima]

Not unless you dig into the partly-obfuscated code and find where WebUI checks for extensions.

[kuzma]

Thanks Ultima for the idea.

I found the following check code in the webui.zip/script.js:

if(!_64.match(".torrent")){alert("The file has to be a torrent file.");return false;

and changed it to

if(!_64.match(".torrent$|\[0-9]{5}$"){alert("The file has to be a torrent file.");return false;

This works fine with no side effects.

[Ultima]

Hm. Not sure why you added those things, but simply commenting the line out or removing it would've worked just fine

[kuzma]

Sure, it is much easy to remove the check at all.

But what happen if the opened file is not the torrent?

I assume that there was some reason for the original check. I just added new pattern for that specific tracker of 5-digits torrent file names.

[Ultima]

Yah, the reason for the check was so that... well, so that µTorrent doesn't get sent a non-.torrent file. For the most part, that works just fine, but as you've noticed, for the servers that don't necessarily link to the .torrent file explicitly (or don't have it named as a .torrent file explicitly), it doesn't work nicely. I'd only asked because your original query was whether it was possible to "use the torrent file as-it-is with no checking the file extension."

[kuzma]

Correct, originally I asked for a help to set some "V" in the uTorrent Preferences to bypass the check at all.

When I didn't get the answer I spend some time finding how to solve the problem by myself. It appears very easy to do the elegant fix instead of code vandalism.

BTW, the new code fixes the original bug (feature?): it was possible in the original code to read, let say, a torrents list file my.torrents.txt as a torrent file, because the filter didn't check end of string after ".torrent". Now it is safer.

[Ultima]

Mm... good point...