Opened 2 years ago

Closed 21 months ago

#2140 closed bug (Fixed)

libtorrent 0.16 and torrent moving

Reported by: elek Owned by: andar
Priority: critical Milestone: 1.3.6
Component: Core Version: 1.3.5
Keywords: Cc: a.starr.b@…

Description

Running Deluge as a daemon on headless system with Arch linux. With libtorrent 0.16.3 when I trying to move torrent storage I get this:

[DEBUG   ] 15:45:18 core:390 Moving storage ('0b02adfe498dac0e76ea9068646e5b97fcb6d2dd',) to /media/anime/[UTW] Accel World
[WARNING ] 15:45:18 core:393 Error moving torrent 0b02adfe498dac0e76ea9068646e5b97fcb6d2dd to /media/anime/[UTW] Accel World

Downgrading to libtorrent 0.15.10 fixes the issue.

Change History (9)

comment:1 Changed 2 years ago by Cas

  • Status changed from new to pending

0.16 is supposed to be backward compatible so this bug should be reported to libtorrent bug tracker.

comment:2 Changed 2 years ago by andar

  • Owner set to andar
  • Status changed from pending to accepted

Actually, I believe the issue is that we're passing Unicode objects to libtorrent when we should be passing UTF8 encoded byte-strings. There was a change made to make the move_storage method use Unicode to resolve an issue on Windows, but I think it's breaking support on Linux with lt 0.16.

We may need to modify the function to behave differently based on the OS.

comment:3 Changed 2 years ago by Cas

  • Component changed from libtorrent to core
  • Milestone changed from 1.3.x to 1.3.6
  • Priority changed from major to critical

Reported on Ubuntu: https://bugs.launchpad.net/deluge/+bug/1041415 with suggested workaround.

As a dumb workaround, I had luck with encoding the parameter to UTF-8.

self.handle.move_storage(dest_u.encode("utf-8"))

comment:4 Changed 2 years ago by andrewsomething

  • Cc a.starr.b@… added

comment:5 Changed 2 years ago by Cas

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

Fixed in 1.3-stable: fc14b008686 and
3309f59333f

comment:6 Changed 21 months ago by gazpachoking

  • Resolution fixed deleted
  • Status changed from closed to reopened

Seems there is still a problem with this. If the dest parameter comes in as an unicode object already it is not encoded to utf-8 before sending to libtorrent. This is compounded by a bug in rencode, which will load strings as unicode objects if they have non-ascii characters, and as byte strings otherwise, no matter whether the string was encoded from a unicode or str object (#2216.)

comment:7 Changed 21 months ago by gazpachoking

Ok, think I have a better solution going on in this branch. Still needs some testing on linux where wstrings are not enabled though. It also fixes file renaming with unicode characters and torrent creation with unicode paths.

comment:8 Changed 21 months ago by Cas

In createtorrent there is another encode(sys.getfilesystemencoding()) in _on_button_file_clicked which needs removed. These changes should fix #2092

comment:9 Changed 21 months ago by gazpachoking

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

Fixed in 7d88cb1850e

Note: See TracTickets for help on using tickets.