Version: unknown (using KDE 3.3.91 (beta1), Gentoo) Compiler: gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7) OS: Linux (i686) release 2.6.9-gentoo wow how pointless: I downloaded a 50mb file with 3mb/s and quickly decided not to do it and selected delete, the window came up but the file finished downloading before Kget managed to delete it and I had to do it myself. Is there a pointless bug award? I demand it. now :)
Created attachment 9671 [details] deletes finished files too As of now finished files are not deleted. I don't know if it makes sense to offer that too. Maybe the finished transfers are not visible anymore anyway. The attached patch removes a transfer whether it is finished or not. There still could be a race condition when the file is being renamed from *.part to *. Don't know where that happens. Felix Berger
CVS commit by fberger: Allow deletion of already finished transfers. There could still be race conditions and the option mark partial isn't honored yet. BUG:96565 M +6 -6 transfer.cpp 1.67 --- kdenetwork/kget/transfer.cpp #1.66:1.67 @@ -456,14 +456,14 @@ void Transfer::slotRequestRemove() dlgIndividual->close(); + KURL file = dest; if ( status != ST_FINISHED ) { // delete the partly downloaded file, if any - KURL file = dest; file.setFileName( dest.fileName() + ".part" ); // ### get it from the job? + } if ( KIO::NetAccess::exists( file, false, view ) ) // don't pollute user with warnings { SafeDelete::deleteFile( file ); // ### messagebox on failure? } - } if (status == ST_RUNNING) m_pSlave->Op(Slave::REMOVE);
Had to reopen it since the patch changed the semantics. This can be fixed after the next message freeze when a distinction between removing the finished transfer object and the underlying file can be made. Maybe a "Clear" transfer table button.
As Downloads stay in the list in the KDE4-Version we just need to offer an option to delete a finished transfer + its files, which itself is a wish. Marking it as that... Lukas