"Verify Local Data" does not check file size

Bug #703221 reported by Sitsofe Wheeler
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
transmission (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: transmission

Description of the problem:
Transmission does not check that a torrent is "small enough" when it is fully downloaded or if it "Verify Local Data" is used. This means that junk on the end of a file is not fixed.

Steps to reproduce:
1. Run
transmission http://download2.bittornado.com/download/BitTornado-0.3.18-w32install.exe.torrent
(or whatever the "download via BitTorrent" link on http://www.bittornado.com/download.html is)
2. Follow the steps to let BitTornado-0.3.18-w32install.exe download (e.g. to ~/Downloads).
3. Run
md5sum ~/Downloads/BitTornado-0.3.18-w32install.exe
4. Run
truncate --size=+1k ~/Downloads/BitTornado-0.3.18-w32install.exe
5. Press the right mouse button over BitTornado-0.3.18-w32install.exe torrent in the Transmission GUI and select "Verify Local Data".
6. Wait for the verification to finish and then run
md5sum ~/Downloads/BitTornado-0.3.18-w32install.exe

Expected results:
The md5sum values returned at step 3 and step 6 to be the same (assuming the file downloaded correctly in the first place :).

Actual results:
The md5sum values returned at step 3 and step 6 are different.

Additional information:
This situation is rare but it really can occur due to bugs elsewhere in the system (see https://bugzilla.redhat.com/show_bug.cgi?id=669511 ). It would be good if "Verify Local Data" was able to fix up such files.

Version information:
Ubuntu 10.04
transmission-gtk 1.93-0ubuntu0.10.04.1

Revision history for this message
Charles Kerr (charlesk) wrote :

Sitsofe, thanks for reporting this.

What, in your opinion, should Transmission do in this odd case?

Should the file be thrown out and restarted? That seems like it could be a curse worse than the disease.

Should Transmission resize the file to the proper size? That seems bad, too.

Unless there's a realistic scenario where this will happen, it might be better to leave the behavior as-is.

Changed in transmission (Ubuntu):
status: New → Incomplete
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Hi Jordan,

The file shouldn't be thrown out or restarted because all the pieces up to its nominal size are correct - there is nothing more to be downloaded. Currently when the file is too small Transmission will make the file bigger and download the missing pieces so if the file is too big I see this as the flip side of the same coin :)

I believe if Transmission is going to check X bytes of data and say the file is correct then it should also check to see that the file is X bytes big and if it is bigger I think it should truncate the file to X bytes. Not doing so means Transmission is subtly lying - the file that is on the disk does not actually match the hash specified in the torrent. I believe rsync will truncate a local file that is larger than what it is being synchronised against...

This really did happen to me on a filesystem where the initial sparse file Transmission created was a little bit too big (see the bug linked in the previous comment) so the downloaded file ended up with NULLs on the end which was enough stop the archive working. Copying the file to another machine and then verifying it said the file was fine when it in fact had trailing data (one of the attractions of torrenting files is that is often able to resume and fix corrupted files). It took some time for me to understand why Transmission was saying the file was OK even though the MD5SUM of what I was downloading was wrong.

Arguing from the from the other side, if truncation isn't going to take place on a file that is too large then verification of local data should fail and tell the user why.

Changed in transmission (Ubuntu):
status: Incomplete → New
Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. If you are still interested in this issue and are still able to reproduce the bug, please fill free to reopen the bug by marking it as new again, or open a new bug with new and updated information with

ubuntu-bug transmission

Otherwise please kindly disregard this message.

Changed in transmission (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for transmission (Ubuntu) because there has been no activity for 60 days.]

Changed in transmission (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.