Summary: | Resuming a copy operation from smb:// fails | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Christian Muehlhaeuser <muesli> |
Component: | general | Assignee: | David Faure <faure> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | adawit, kdelibs-bugs |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Screenshot |
Description
Christian Muehlhaeuser
2013-03-20 01:11:00 UTC
Can't reproduce. If I abort the copying of some hello.avi, there will be a hello.avi.part left in the destination folder, and when I start a new copy to the same destination, it will just overwrite that hello.avi.part without asking. So, which KDE version is this report about? (you should really always provide this information for every bug report) Sorry, updated. 4.10.1, ArchLinux packages. Created attachment 78232 [details]
Screenshot
Resume will only work if the server supports resumption. If it does not clicking on "Resume" will be treated as if you wanted to download again. I cannot duplicate this with my own local test either. A resume operation is properly resumed. Does this issue happen against one single smb server or every smb server you connect to? I can still reproduce this with smb:// and fish:// for all servers I'm working with. Thanks for the update, changing status. Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you! This seems to be resolved and working now. |