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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/703221
Title:
"Verify Local Data" does not check file size
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
