Opened 10 years ago

Closed 10 years ago

#4428 closed Bug (fixed)

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

Reported by: cantabile Owned by: jordan
Priority: Normal Milestone: 2.40
Component: Qt Client Version: 2.33
Severity: Minor Keywords:
Cc:

Description

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.

Attachments (1)

2011-08-18-085555_302x110_scrot.png (5.9 KB) - added by cantabile 10 years ago.
Weird characters appear instead of ☆

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by cantabile

Weird characters appear instead of ☆

comment:1 Changed 10 years ago by jordan

  • Milestone changed from None Set to 2.40
  • Status changed from new to assigned

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

comment:2 Changed 10 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:3 follow-up: Changed 10 years ago by rb07

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

Last edited 10 years ago by rb07 (previous) (diff)

comment:4 in reply to: ↑ 3 Changed 10 years ago by rb07

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

Last edited 10 years ago by rb07 (previous) (diff)

comment:5 Changed 10 years ago by rb07

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.