| Summary: | KGet overwrites data when trying to rename file from *.part to * | ||
|---|---|---|---|
| Product: | [Applications] kget | Reporter: | agentgates |
| Component: | general | Assignee: | KGet authors <kget> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | oasalonen |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
agentgates
2006-08-02 10:34:40 UTC
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 |