Conversion to QString in "New torrent" dialog assumes the input string is ASCII (it's not)

[cantabile]

To reproduce the problem, create a torrent from a folder whose name contains ☆ or ū or any non-ascii character, really. Instead of those characters, the new torrent's file name will contain some weird stuff (see attached screenshot).

I tracked down the problem to line 147 in make-dialog.cc#L147:

    myTarget = QDir( myDestination ).filePath( QFileInfo(myBuilder->top).baseName() + ".torrent" );

Specifically, the QFileInfo(myBuilder->top) part. myBuilder->top gets converted to QString ​with the assumption that it was ascii.

In my case, the string in question was utf8, so QFileInfo(QString::fromUtf8(myBuilder->top)) fixed the problem. However, this only replaces one assumption with another. :( I don't know how to fix this so that it would work on systems where the file names are stored differently (I heard something about windows using utf16 internally?).

This assumption is present in a few more places in make-dialog.cc (for example, line 82).

Transmission version is 2.33. Operating system is arch linux x86_64. File system is ext4. Locale is en_US.UTF-8.

[cantabile]

Weird characters appear instead of ☆

[jordan]

Fixed in r12697, along with many other ascii-to-QString assumptions.

[rb07]

Your changes don't work on Windows.

Two interesting points:

• I had this working fine on my Windows port just using fromUtf8, not fromLocal8bit. But I haven't tested if that is the problem, or the other changes are;
• The error message shown is way off base: 'Error reading "././config/blocklists/blocklist.bin": Permission Denied'; and it writes "C:/tmp/test/.torrent" to the console, that's probably the name of the file it tried to use (missing the actual name, which has only one accent). My test was trying to create a .torrent that has foreign characters in its name, contents, and comment. The blocklist has nothing to do, and its being read fine, even updated fine.

A test with another group of files, all with names in English, fails with the same error and console message.

[rb07]

Hold on, it seems that the problem is elsewhere, I'll have to use the debugger.

[rb07]

OK, sorted out: the strange error was caused by my (bad) implementation of realpath(), which Windows doesn't have.

The use of fromLocal8Bit() almost works, but fromUtf8() works completely. As the code is at the moment, plus my changes for Windows (which translates from UTF8 to Windows native UTF16 file and directory names), produces a good .torrent file but with a wrong file name.

I'm closing the ticket since I'm not going to test if it works on Linux to prove that my other changes are causing the wrong file names or not.

BTW another difference is that I use completeBaseName() instead of baseName(), think of all those files with names where dots replace spaces.