Windows WebUI Bug

The situation is the same on 2.8.4, too.

This is fixed for next release. Thanks for the report.

Unfortunately, the bug still exists in 2.9.0beta :(

Thanks for the feedback, I'll see what went wrong.

Ok, I think I understand what was wrong with my fix. I refactored the code and it should work now.
I'll upload beta2 today for you to test, please reopen if you still experience the issue.

It's still the same with 2.9.0rc1. :(
Just for reference - now I'm trying with localhost:8080 because I'm not on my remote computer, but anyway everything is the same.
However, it will be good if someone else try to reproduce this bug as well.

Ok, assigning to sledgehammer then.

@Sledge: Could you please try to reproduce this? the problem is likely to be in src/webui/httpconnection.cpp.
The error message "Unable to decode torrent file: 'C:\Users\skrech\AppData\Local\Temp\qt_temp.Va3332'" hints that we generate a temporary file for the torrent which does not have .torrent extension. Windows does not like that.
However, I patched httpconnection.cpp to make sure the generated tmp file has a .torrent extension and it seemed to work fine on Linux.

@skrechy Don't worry I am able to reproduce the bug, so I'll be doing the testing too.

@Christophe
I am not sure what happens but the 'downloaded' torrent isn't valid. Maybe it isn't transferred correctly or whole. I'll try do understand the code logic of the web ui but don't hold your breath :p Meanwhile. keep the solutions coming, I'll be able to compile and test them.

I'll attach the original torrent and the one qbt saves in the temp file

Looks like the file may be written in text mode instead of binary mode on Windows. Probably QIODevice::Text flag is enabled.

Unfortunately, the public QTemporaryFile::open() does not take flags in parameters. The one that takes flags in is protected.
I think we should try to subclass QTemporaryFile and make sure open() calls open(QIODevice::ReadWrite) internally. I have a feeling this would work.

The other alternative is to use QTemporaryFile only to generate the filename and then use QFile to actually write. However, this is not very clean and I would prefer if we avoid that.

Should I wait a patch from you or **try** to implement it myself?

I think I found an easier solution. I should use setTextModeEnabled(false)...
I'll test it in a few hours and report back.

Good idea. I prefer you take care of it since you are able to test. I tried to fix it twice blindly and it did not work.

I put setTextModeEnabled(false) before and after open() but it didn't fix the bug.

Do you have any other idea? Maybe the torrent-data are incomplete? How is that possible?

From where does m_parser get it's data? How and when are the data fed to it? (I am just trying to understand the code)

I'm pretty sure that's the problem (the torrent is clearly written in text mode instead of binary mode on Windows).

You should try to subclass QTemporary file as I said, or use QFile instead.

I used a QFile instead of a QTemporaryFile and pointed it to a free location. I opened it with .open(QIODevice::ReadWrite) but the same thing happened.

Are we sure that the data are parsed correctly? That the torrent-data are whole when written to file?

Strange...

The parser is at src/webui/httprequestparser.cpp , you can have a look and make sure it is doing its job OK.

However, try to open a regular torrent file (with vim for example) and compare it to the ones you uploaded. The difference I see is that those you uploaded did not seem to have binary in them, only text chars. For this reason, my assumption was the binary writing issue.

Then again, it is entirely possible that the data get corrupted (converted to text) *before* writing. For example, if the QByteArray is converted to a QString and then converted back to a QByteArray. We should check the code for that, just in case.

Yes, please double-check the parser if you have time. This looks suspicious:

m_torrentContent = m_data.right(m_data.size()-m_data.indexOf("\r\n\r\n")-QByteArray("\r\n\r\n").size());

Actually, you're right. I did not see that you posted the original torrent. It does indeed look incomplete... :(

I cleaned up the parser code a little and added some more debug, maybe this will help.

I tried the new code. It didn't fix it.

Sledge: Did you read my post? I never said it would fix it. I merely added some debug for you to find the issue. It works just fine on Linux so I'm unable to debug this.

I'm have rewritten the multi-part/form parser code. It should be more robust now. I have no idea if it helps or not on Windows.
Also, there is useful debug output now. I would be interested to see the output on Windows.

I have an idea. Could you try another browser than IE? I have a feeling this has nothing to do with Windows, but only another IE weirdness. IE probably does not send the multi-part/form data the same way and it breaks our parser.

I'm fairly confident this is fixed now.

@Sledge: Could you please confirm?

I was able to reproduce the issue from a Windows machine using IE9 and qBT running on a Linux server. This helped me debug.

I am using Firefox to test. (ver 6 and 7)

No it didn't fix it. Also now, the "download dialog" of the webui hangs there and doesn't disappear.

Here is what I get from the debug build in the console

void __thiscall HttpRequestParser::writeMessage(const class QByteArray &) m_data
.size(): 13721
void __thiscall HttpRequestParser::writeMessage(const class QByteArray &) header
 is: "POST /command/upload HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: el
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-7,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://localhost:8080/
Content-Type: multipart/form-data; boundary=---------------------------411846763
34
Content-Length: 13721

"
Boundary is "-----------------------------41184676334"

Before binary data: "-----------------------------41184676334
Content-Disposition: form-data; name="torrentfile"; filename="[i?εi??-Raws]Nichi
jou - 26 END.mp4.torrent"
Content-Type: application/x-bittorrent"

found end boundary :)
void __thiscall HttpRequestParser::writeMessage(const class QByteArray &) m_torr
entContent.size(): 13484

void __thiscall HttpConnection::respondCommand(const class QString &) upload
Adding C:/DOCUME~1/SLEDGE~1/LOCALS~1/Temp/qBT-Ri2752.torrent to download list
Loading torrent at "C:/DOCUME~1/SLEDGE~1/LOCALS~1/Temp/qBT-Ri2752.torrent"

Looks like it was parsed successfully.

What size is the torrent supposed to be (check size in bytes with ls -l file.torrent).
It detected 13484 bytes.

Could you check the downloaded torrent file in C:/DOCUME~1/SLEDGE~1/LOCALS~1/Temp/qBT-Ri2752.torrent ?
See if it looks complete and propertly encoded.

Also, what is the error message when loading the torrent?

Original torrent file size: 13484
Downloaded torrent file size: cannot capture it. It gets deleted.(by the destructor of QTemporaryFile). I'll disable it later and recompile. Assume same size as the one I uploaded earlier.

Error message from execution log:
02/10/2011 18:36:18 - Unable to decode torrent file: 'C:\DOCUME~1\SLEDGE~1\LOCALS~1\Temp\qBT-aq2760.torrent'
02/10/2011 18:36:18 - This file is either corrupted or this isn't a torrent.

Don't assume :) The parser says it got 13484 bytes too, this is a good sign. This means the parser got the whole torrent.
Please do check the generated tmp file (of course you need to disable auto-deletion). I'm pretty sure it'll have correct size.

I'm delaying v2.9.0 release because of this bug. I hope we can resolve this soon as I have Linux-related deadlines.

Finally, we have some progress.
The downloaded file is also 13484 bytes and the md5sum of the original file and the downloaded one match. It is copied/downloaded whole and correctly, but it still isn't recognized as a valid torrent. But if I add the downloaded file from the GUI it is recognized as a valid torrent file. :S

Ah, that's what I thought. Then the problem is the PATH:
'C:\DOCUME~1\SLEDGE~1\LOCALS~1\Temp\qBT-aq2760.torrent'

those DOS ~1 abbreviations probably confuses the our code. We probably need to get a real unshortened path for the torrent.
I'm not sure how though :)

I am really frustrated by this. I was looking for way to get the long filenames instead of the short ones but didn't find anything. So, to test your theory, I hardcoded my temp path for the 'torrentReadyToBeDownloaded' signal but I still get the same output in the "Execution log". Probably the bug lies somewhere else entirely...

I don't see where else the problem could be. The next function that's called is qBtSession::addTorrent() but this is a core function and it has to work. Are you sure you hardcoded the temp path properly?

If the file is complete and can be loaded manually afterwards, the only possible explanation *is* that the path given to addTorrent() is incorrect (or not interpreted correctly). There is debug output in addTorrent() so you could check the path that it tries to load from the terminal output.

Ok, this is finally fixed (sledge, please double-check to be sure).

The trick is that the QTemporaryFile object needs to be destroyed *before* loading it with addTorrent() or it will complain that the file is locked (or used by another process) on Windows. Interestingly enough, I was already aware of the issue and had already fixed it in downloadthread.cpp. Unfortunately, it was so long ago I just forgot about it.