non-ascii chars in file names kill threads?

Ask for help and report issues with the Windows version of Transmission
Post Reply
powertower
Posts: 3
Joined: Mon Jan 06, 2020 1:33 pm

non-ascii chars in file names kill threads?

Post by powertower » Fri Jan 10, 2020 2:09 am

Okay! This is related to my previous bug report. I'm running 3.00+ (f041f229bf) on Windows 10 and it handles the bug more gracefully than the previous version I was using, in that it displays an error message including the file name, so I can exclude the file name and download the rest of the affected torrent.

The current torrent that is triggering the bug has the word Café -- complete with the accent mark -- in the name of a directory. This word appears in the file listing in properties as "Caf?". The previous torrent I had this problem with also had a question mark in the name of the file that wouldn't download, in properties. So I'm suspecting that something is up with Transmission's handling of non-ascii characters, at least on Windows.

That's my bug report :) have a nice day

powertower
Posts: 3
Joined: Mon Jan 06, 2020 1:33 pm

Re: non-ascii chars in file names kill threads?

Post by powertower » Sat Jan 11, 2020 12:04 pm

This is just a windows/qt thing -- I successfully got the accent-having-in-their-names files with the GTK transmission that's part of the cygwin distribution. I looked at the win32-files.c file on github but didn't readily find wherever it converts the torrent's file names to UTF16 or whatever windows "wide" file names are in, but it seems like that might be where the problem is. But here's a feature request -- transmission should check the file system to see if the files it wants to download are already there, like they've magically appeared while it was off, before trying to continue downloading them. It might actually do this for files that haven't got accent marks in their names, but after copying the files that cygwin/GTK got into the directories where qt-current would have downloaded them to if it could, qt-current failed to note that they were already there even after "verify local files."

Post Reply