Bug 51450 - No resume option when there is a file with the same name
Summary: No resume option when there is a file with the same name
Status: RESOLVED INTENTIONAL
Alias: None
Product: kget
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KGet authors
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-12-03 02:05 UTC by ismore
Modified: 2010-01-02 00:23 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ismore 2002-12-03 02:05:59 UTC
Version:           v0.8.3 (using KDE 3.1.9)
Compiler:          gcc version 3.2
OS:          Linux (i686) release 2.4.19-gentoo-r9

If I try to download a file that I've already download with another program, KGet only asks to overwrite, no resume.

This can happen if I started to download the file with some program (wget for example) and later switched to KGet. I know that it can't know if it's the same file or just another file with the same name, but I think that there should be a resume option, even if there isn't a .part.

Or at least a short message telling the user to rename it to .part if he wants to resume the download.
Comment 1 Jaroslav Lukesh 2004-04-01 12:08:38 UTC
When MarkPartial=false is at ~/.kde/share/config/kioslaverc

kget is not able to do partial downloads
Comment 2 Mathieu Jobin 2006-01-11 08:30:16 UTC
was about to create a new report, not sure if kget is still what is handling download, but anyway, got a download interupted and getting back to the download link is a pain, i thought that staled download could have had a "resume" or a "retry" button.

also, I thought, "what if .part would be .download instead, with download info, so user could simply double click the partially downloaded file to automatically resume it ?

Comment 3 Matthias Fuchs 2010-01-02 00:23:52 UTC
We won't implement the initial request as it is impossible to guess how much of the file has been downloaded by the other program. Other programs could create the complete file e.g. 10 MB and then download random parts, or the filesize could resemble the actual downloaded size. Imo one should simply not switch download managers for unfinished downloads.

On Mathieus issue restarting transfers is supported in KGet, so that should not be an issue anymore. Further .part files are something of KIO, so essentially have nothing to do with KGet itself. As finished downloads remain in the list and are also added to the history one can also easily look what the url of failed downloads is.