[win32] 'open-with' does not work for non-acsii torrents

[IAmTheClaw]

The UI cannot open .torrent files with Unicode characters via the OS "open file with" or via download. In the former case, the UI silently ignores the error and in the latter case, it says it cannot find the file. Downloading the .torrent to disk and then opening the file through the "Add Torrent" dialog works, however.

OS: Windows 7 x64

Deluge daemon and client are both version 1.3.5.

[Cas]

I have verified that the open with issue exists and it is a problem with windows non-ascii chars passed as python args.

There is a  stackoverflow workaround that seems to work but it may affect other parts of the code so will need further testing.

For reference: ctypes.wintypes module will need including if not done automatically by bbfreeze.

[globeaddict]

Same problem on Linux.

When using french tracker, some torrents are named with accented characters (éàè...). The problem occurs both with autoadd plugin and by adding it manually. The torrent downloads as expected but doesn't appear anywhere in my torrent list. And when I try to display the list of labelled torrents in which it belongs, nothing happens, as well as "all" label list.

The solution is to stop autoadd plugin and rename the torrent before adding it manually.

[Cas]

@globeaddict: That is a different issue see #1983

[gazpachoking]

This seems to work, tested on Windows 7 x64. Some other people should test it though, I'm never quite sure with this encoding stuff.

deluge/ui/gtkui/addtorrentdialog.py

@@ -41 +41 @@
 import base64
 import logging
 import os
+import sys
 from urlparse import urljoin
 
 import twisted.web.client
@@ -214 +215 @@
 
         for filename in filenames:
             # Convert the path to unicode
-            filename = unicode(filename)
+            filename = unicode(filename, sys.getfilesystemencoding())
 
             # Get the torrent data from the torrent file
             try:

[gazpachoking]

That patch was on master, I just tried 1.3-stable, and it seems like it's already working. This commit seems to have fixed it  370035ffc5e I think there should probably be a sys.getfilesystemencoding() in there though, or at least 'mbcs' if it's on windows, as windows can use a configurable encoding, looks like mine just happens to be latin-1.

[gazpachoking]

For reference  http://docs.python.org/2/howto/unicode.html#unicode-filenames

[Cas]

I'm afraid the issue is not in the add dialog but in ipcinterface because optparse can't handle the unicode filenames as arguments. The only solution for 1.3 is to add the associated code from stackoverflow and in git master maybe move to argparse however that would force py2.7 requirement.

[gazpachoking]

Ok, pretend all my other comments don't exist. Turns out my old way just worked with characters which were in the ansi code page which windows uses in its backwards compatible api. I believe I am much closer to the real solution now in this  branch (here's the  diff) It works when calling deluge-gtk with unicode arguments, however in my testing it didn't work when double clicking a torrent from the system. I can't figure out how that could be, so maybe I'm testing wrong. It has the added benefit of also allowing unicode config directory and log file paths. This branch also needs to be tested on linux (and osx) to make sure nothing got messed up.

[gazpachoking]

I think for 1.3-stable maybe we just keep the commit Cas already added, which should allow torrent/path names within the ansi code page (essentially latin-1.) Decoding all arguments to unicode, like my proposed branch, is a bit more dramatic change. Ultimately these problems should all be solved on python 3 (without hacks,) if/when we go that route. The problem with python 2.x is that the standard library uses the backwards compatible Windows api in several places, which does not allow for the full unicode support that Windows uses natively.

[gazpachoking]

So, it turns out the problem with file association opening is that when using the .exe instead of the python script to launch, the arguments already come through with the question marks. I am unsure if this is also the case with the .exes generated by bbfreeze as well. (I was testing with the ones made by setup.py) Other than that, everything is running as it should on the new branch (on Windows.)

[gazpachoking]

I verified that exes from bbfreeze do not have the same problem as the exe wrappers generated by setup.py, everything should work fine with this branch once it's made into a bbfrozen package.

[Cas]

@gazpachoking So there is not going to be any fix applied to 1.3-stable?

For testing, ticket #1388 has steps to reproduce the issue.

[gazpachoking]

Well, it's already partially fixed in 1.3-stable, at least latin1 characters work now instead of just ascii. We could certainly apply the full fix to 1.3-stable too, I was just a little worried about unforeseen repercussions of going to entirely unicode arguments.

[gazpachoking]

Fixed in master  c2d301bf52