Opened 7 years ago

Last modified 8 months ago

#3028 new bug

Moving torrent corrupts torrent pieces

Reported by: qengho Owned by:
Priority: minor Milestone: needs verified
Component: Unknown Version: other (please specify)
Keywords: Cc:

Description

"Force Recheck" shouldn't exist. If Deluge and its underlying technology worked as advertized, then there would be nothing to check.

As it is, I work on a filesystem with block-level checksums (so I am certain my disks are not flipping bits), and every torrent is claimed to download successfully, run their post-download move trigger, and then stop.

About 1/5th of the time, running "Force Recheck" discovers some problem, and Deluge then restarts the download phase at about 90%.

That shouldn't happen.

Moreover, there should be no "Force Recheck" button at all. That is an excuse for shrugging the burden of broken software behavior off onto the user. If libtorrent or deluge worked, then there would be no reason to recheck.

Change History (2)

comment:1 Changed 7 years ago by Cas

  • Summary changed from "Force Recheck" menu option is an acceptance of bugginess to Moving torrent corrupts torrent pieces

The Force Recheck button is staying.

The problem with corrupt pieces is an issue that should be investigated but you will need to provide more information as it is libtorrent or file-system issue.

comment:2 Changed 7 years ago by qengho

Ubuntu 16.04 (and every version for several years).

libtorrent-rasterbar8 1.0.7-1build1 amd64
deluge 1.3.12-1ubuntu1 all
deluge-common 1.3.12-1ubuntu1 all
deluge-console 1.3.12-1ubuntu1 all
deluge-gtk 1.3.12-1ubuntu1 all
deluged 1.3.12-1ubuntu1 all

Filesystem is ZFS, which writes a checksum on every block and verifies it upon reading it off. Problem isn't the filesystem.

I do have the configuration set to move the downloaded files to a new location upon completion. If that is using rename() (or renameat()!), then open file descriptors are unaffected so the config setting doesn't affect whether the download is completed. (If it's copying file blocks, giving it a new name, and then removing the original, it could be some kind of race.)

Could you suggest some way to reproduce or debug?

Note: See TracTickets for help on using tickets.