Version: v0.8.5 (using KDE KDE 3.5.1) Installed from: Fedora RPMs OS: Linux I was downloading a 1.6GB file to a network filesystem. During the download our system administrator has changed permissions on the target directory, however the download was still running. When I have got the entire file and kget tried to rename .part file, I've got an error window as well: "Permission denied" or something similar. I told the sysadmin to change the permissions on that directory. Afterwards I tried to "Resume" the downloading to perform renaming, but kget has overwritten my 1.6GB file and restarted to download it!
I have downloaded this file again to the same target directory, but this time chmod 666 was applied on the target directory and nobody had touch the permissions. The problem was just the same. No problem during the download, but when kget wanted to rename it at the end, it has given an error message related to directory permission just like before. So, I took another walk and tried on firefox as well to the same directory, and everything was running fine.
I'm using KDE4 trunk sources, so the code is probably different than when this bug was reported. For example, no error is given when the directory permissions are changed to 666. When directory permissions are changed during the download and the download is finished, the .part file is not renamed and the KJob finishes. It calls TransferKio::slotResult() with no error code (0). kget assumes the download is fine and reports it as finished. If the directory permissions are reverted afterwards, clicking Start/Resume will not rename the .part file because kget considers the download finished. Perhaps an additional check should be made when the Start/Resume is clicked for the existence of the .part file? It cannot be done during the call of TransferKio::slotResult() because directory permissions would not allow examining the directory contents. Or in this case, kget could assume the renaming did not succeed if right after finishing the download the directory has no exec permissions. Any thoughts from the kget devs?
Hey! Start/Resuming a finished download is not really possible imo, it has a real bad bug: Some webservers don't tell the total-size to KIO/KGet and/or cannot resume downloads... so that check would fail in some cases... Lukas
Ok, that would definitely make it difficult. However, does KJob give a certain error code for a cut-off download? In this case it would be possible to differentiate between a partially downloaded transfer and one that failed after fully downloading. But even if this were the case, it would require more extra logic, more user interaction, and possibly introduce other obscure bugs to fix a fringe case.
Yeah, here are all error-codes KIO can give us: http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/namespaceKIO.html#e3b43d88fc092c0f5380cf97ca4256a7 ERR_CANNOT_RENAME_PARTIAL <- that might be our interest... Lukas
We don't have .part files anymore in kget... closing this... Lukas