Version: 2.0.80 (using 4.00.81 (KDE 4.0.81 >= 20080527), compiled sources) Compiler: gcc OS: Linux (i686) release 2.6.22.18-laptop-1mdv I downloaded a bzip2 archive via KGet http://quassel-irc.org/system/files/quassel-0.2.0-beta1.tar.bz2 and I saved it. When I untarred it I got the following error: quassel-0.2.0-beta1/src/icons/quassel.icns bzip2: Data integrity error when decompressing. Input file = (stdin), output file = (stdout) It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now I tested the file by downloading it with wget in Konsole and I was able to untar it correctly. file quassel-0.2.0-beta1.tar.bz2 and ls -la give the same information about the archive.
wget [kde4@localhost tmp]$ md5sum quassel-0.2.0-beta1.tar.bz2 246881ecc4d7e7a0eb98a2fa6bfbac64 quassel-0.2.0-beta1.tar.bz2 kget [kde4@localhost ~]$ md5sum quassel-0.2.0-beta1.tar.bz2 6765baaa91165fdf28d1e3c0417b3bdf quassel-0.2.0-beta1.tar.bz2
KGet is used with the default settings: 5 segments and all defaults
32 bit machine, thanks to boom1992 for guiding me on IRC and making this report perfect!
Reason: quassel-irc.org does not support resuming (and returns response 200 instead of 206), but KGet blindly assumes that it does. As a result each fragment contains beginning of the file. When used with server that does support resuming, KGet downloads files correctly.
Well I tried a totally random bzip2 http://dfn.dl.sourceforge.net/sourceforge/amsn/amsn-0.97RC1.tar.bz2 and it's the same so it seems that lots of servers do not support resuming.
So in that case. kget have to download the file only in the very first change? you cant stop and resume or close kget and resume later? if that is the case we need to make some changes. btw any hints for how to implement this?
It would be good IMHO if KGet would show a warning for such a file when the user want to stop it / quit KGet that it is not possible to resume it. Also multithreaded downloading should be disabled for such servers since that will not work. If the user quits KGet or pauses the file, the download has to start from beginning again.
*** Bug 162421 has been marked as a duplicate of this bug. ***
Please try again. SVN commit 825276 by mvaldes take into account the resuming capabilities of the transfer this should fix bug:163617 but i dont close it until more testing. please feel free to check it and add some feedback
This should be fixed in 4.1... Lukas