does not handle updated file images with changed md5sums

[Walter_Wittel]

Binary package hint: transmission

Last night I started downloads of desktop-i386 and desktop-amd64 isos from http://cdimage.ubuntu.com/releases/jaunty/alpha-3/.

This morning when I verified the md5sums they were both wrong. Unfortunately Transmission has also been serving these bad images out, so I suspect others have bad iso images also. Besides using ubuntu-bug to attach system info I have also attached the amd64.iso.torrent file I got from the cdimage site.

So far I have downloaded the i386 iso directly from the site and the md5sums verify on that image.

BAD MD5SUMS FROM Transmission DOWNLOAD
0a31556ec555f51a8fea2bd4af7bd6cb jaunty-desktop-amd64.iso
3c9a7bec30a00781b4d077a2fd9ec499 jaunty-desktop-i386.iso

Please let me know if I can supply any additional relevant information.

Aside from a bug or limitation of Transmission that allows it to download and then share out a bad ISO image, it seems for new users of P2P like me the default should be more secure (e.g. download is not shared with others until user approves (and is warned to do an md5sum to prevent polluting the world).

ProblemType: Bug
Architecture: amd64
Dependencies:

DistroRelease: Ubuntu 8.10
Package: transmission None [modified: /var/lib/dpkg/info/transmission.list]
PackageArchitecture: all
ProcEnviron:
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: transmission
Uname: Linux 2.6.27-11-generic x86_64

[Walter_Wittel (wittelw)]

Doesn't look like ubuntu-bug attached any OS or package info. Here is the minimum. Let me know what more you need.

Description: Ubuntu 8.10
Release: 8.10

transmission:
  Installed: (none)
  Candidate: 1.34-0ubuntu2.2
  Version table:
     1.34-0ubuntu2.2 0
        500 http://us.archive.ubuntu.com intrepid-updates/universe Packages
     1.34-0ubuntu2 0
        500 http://us.archive.ubuntu.com intrepid/universe Packages

I've also attached the i386 torrent file while I'm at it...

[Walter_Wittel (wittelw)]

OK, here's the repro:

1) Use Transmission to download an ISO (example Jaunty Alpha 3 jaunty-desktop-amd64.iso) to ~/isos.
2) Checksum verifies fine for the downloaded file.
3) Later when Jaunty Alpha 4 is released use transmission to download the new ISO (same name for Transmission and downloaded to same directory).

Result: Checksum for jaunty-desktop-amd64.iso FAILED. Transmission has been happily sharing the bad image with the entire world :-(

As an experiment I deleted the Alpha 3 jaunty-desktop-i386.iso from ~/isos and the new Alpha 4 image checksum is correct.

I would expect at least a warning and deletion of the old version from Transmission if it can't handle downloading a new version by the same name.

I hope someone can respond to this bug and if more information is needed or it needs to be posted elsewhere let me know. Thanks.

[Charles Kerr (charlesk)]

Walter: did you remove the old torrent from Transmission (not from the disk, but from Transmission) before adding the new one?

[Walter_Wittel (wittelw)]

I don't recall. The file (of the same name) was definitely still there in the download directory but I didn't open Transmission first. I clicked the torrent link on the Jaunty download page and that launched Transmission (with a dialog to add the torrent).

For Alpha 5 I just deleted the .iso files from the download directory, clicked the torrent links, added the new torrents, and everything worked fine.

Maybe a dialog warning allowing a delete of an existing file of the same name or cancel would do the trick for this scenario.

[Walter_Wittel (wittelw)]

For Alpha 6 I left the files and Transmission in the prior state (Alpha 5) and fired up Transmission. Both torrents in Transmission were highlighted in red and said "Requested download is not authorized for use with this tracker - idle".

That also jogged my memory. For Alpha 3 -> Alpha 4 experiment I now remember having three torrents, the two new Alpha 4 torrents and one in red (the Alpha 3 with both the old torrent and the old Alpha 3 jaunty-desktop-amd64.iso file. I now remember deleting that "dead" torrent but leaving the old iso file, which after download was complete didn't pass the checksum.

So while I was warned about the torrent I wasn't informed I needed to manually rename or delete the target file. This warning or rename / delete after prompting the user needs to be taken care of when adding the torrent via a link (for example clicking a link on http://cdimage.ubuntu.com/releases/jaunty/alpha-6/) and also when removing an "idle" torrent from the Transmission UI.

Hope this helps clarify. Thanks for your interest in improving Transmission!

[Corey Burger (corey.burger)]

This seems to be a generic bug with Transmission and checksumming downloaded files. It will happily tell you that the files are correct until you move them to another folder and actually force transmission to recheck. Even "verify local data" doesn't work. Not having looked at the code, there is a pretty serious bug here that needs to get sorted.

[Hew (hew)]

Does this problem still occur with Transmission 1.51 and Ubuntu Jaunty?

[Walter_Wittel (wittelw)]

This problem (bad checksum after downloading a newer version of the same file with a different checksum) did not happen upgrading a Karmic Alpha 2 file over the Alpha 1 version (Jaunty and Transmission 1.51). I'll assume it still exists in 8.10 but have moved on. The checksum of the overwritten file was fine after the download finished. Thanks for the fix!

I did experience a problem where, after adding the streams and deleting the old entries in the Transmission GUI (indicated appropriately in red with a warning message), I never connected to any peers. I tried exiting and restarting Transmission from gnome with no luck and found I had to kill the process (no UI) before restarting, at which time everything worked as expected. I'll try this scenario again for my Alpha 3 downloads and file a separate bug if it repros (unless you can confirm this as a problem not).

[Charles Kerr (charlesk)]

When upstream ticket <http://trac.transmissionbt.com/ticket/2228> was filed yesterday with the summary "transmission should learn to truncate files on updating torrents" it reminded me of this ticket. IMO #2228's summary describes what's happening here.

What's happening is that when the updated iso is smaller than the earlier version, Transmission wasn't truncating the file, so the file checksum fails. However, the BitTorrent *piece* checksums are still correct, so you were *not* sharing bad data to the rest of the world.

At any rate, since upstream #2228 spelled out what was going on and how to fix it, this is fixed in upstream svn trunk in <http://trac.transmissionbt.com/changeset/8726> for 1.73.

[Walter_Wittel (wittelw)]

FYI I was able to repro the problem from my last message when downloading Alpha 3 and opened https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/405609.

Thanks for the (confirmed) fix for this bug!

[Launchpad Janitor (janitor)]

This bug was fixed in the package transmission - 1.73-1ubuntu1

---------------
transmission (1.73-1ubuntu1) karmic; urgency=low

  * Merge from Debian unstable: (LP: #401578)
    - Fixes bugs (LP: #318249) (LP: #388348) (LP: #391995) (LP: #394080) (LP: #374013)
    - Remaing changes same as in 1.72-1ubuntu1
  * debian/control:
    - Added BZR link

 -- Robert Ancell <email address hidden> Mon, 20 Jul 2009 15:28:53 +1000

[Walter_Wittel (wittelw)]

Please ignore my confirmation of the fix. I didn't have 1.73 installed and must have gotten lucky with larger ISOs.

I have downloaded 1.73 from the ppa onto my Jaunty box with the Alpha 3 state and will see if I can confirm again on the Alpha 4 download.

[Walter_Wittel (wittelw)]

I duplicated this repro scenario using 1.73 on Jaunty installed from the PPA and did not see any of the symptoms. The MD5 checksums (as well as SHA256) were correct on the iso's after download. Thanks for fixing this!