![]() Registered Member ![]()
|
I may have found a couple of bugs and did not see anything in the changelogs that address these issues... So please excuse me if these have already been corrected as I have ktorrent 3.2.1. I have it set to not zero out files. I have it also set to pre-allocate files. With some large torrents (1000+) files I sometimes end up with several corrupt files. Now my first inclination was that the torrent was serving up garbage data. I had the originator of the torrent check their files and they were correct. So I fired up uTorrent and tested the items I had downloaded with ktorrent and it passed there as well.
This leads to my first bug (uTorrent is doing the same thing). This is also pretty easy to verify. If you take a file and add extra junk to the end of the file. Making sure to keep the front part of the file correct. However there is 'extra' data in the file. This file will pass the data check. I think this works because the block checker stops at whatever number of blocks are specified in the .torrent file. So I did not even know I had a corrupt file until I went to unzip the file. Which leads to my second issue. It also appears randomly. Every once and awhile I end up with 'extra' data tagged onto the end of a file. It usually seems to be the data from the next file (especially if both files are contained in the same block). Yet the next file is correct in data and in size. Also the 'front' part of the file is correct as well. If I truncate the file to be the correct size the file still passes the torrent checks, as well as now being a valid .zip file. This may have nothing to do with it but I will state it anyway. I am also doing 'incremental updates'. What that means is some percentage of the files will be new. Some percentage will be updated. Not sure if that will have anything to do with it. But it might. In the other forum where I reported this issue (as I thought the torrent was corrupt) they mistakenly thought I was using utorrent for the whole thing and found the same two bugs there as well. So this may stem from a specification deficiency as well. |
![]() Moderator ![]()
|
The file sizes are specified in the torrent, so there is no reason for a torrent client to append some additional data to a file.
Do you have a torrent where this can be easily reproduced ? |
![]() Registered Member ![]()
|
I have been told that this torrent produces the effect fairly reliably in uTorrent (a few have reported that it does not happen every time). I also had the same effect with the same one in ktorrent but not as bad.
http://mametitles.com/titles/MAME_Title ... orrent.zip It was the fact that it did not pick up the corruption is what concerned me the most. As I can delete the files and just redownload them (when I find them). The corruption itself is concerning too. |
![]() Moderator ![]()
|
Something in the back of my head is telling me that I have seen this before, it had something to do with a MAME torrent.
|
![]() Moderator ![]()
|
It took me a while to find it, but this bug was fixed in version 3.3.3:
https://bugs.kde.org/show_bug.cgi?id=222036 |
![]() Registered Member ![]()
|
ROCK ON!!!
Already fixed too! My favorite kind of bug. That will teach me not to upgrade to newer software for a year ![]() That gets the corruption part. But was there ever anything to detect that it had happened? As now I have a bunch of files that may or may not be corrupt ![]() |
![]() Moderator ![]()
|
The fix only prevents it from happening. You could write a script to truncate the files, the file sizes are in the torrent. So the script would just have to parse the torrent and truncate each file to the correct size. Not something a non programmer could easily do. |
![]() Registered Member ![]()
|
I was afraid of that
![]() Just been trying to avoid writing something if I could, if the tool already did it. Thank you. |
Registered users: Bing [Bot], blue_bullet, Google [Bot], rockscient, Yahoo [Bot]