[krusader] [Bug 419266] Copying file continues for 8 seconds after canceled
https://bugs.kde.org/show_bug.cgi?id=419266 --- Comment #6 from Christoph Feck --- I cannot reproduce, neither with Plasma's progress dialog, nor KIO's fallback window. I tried with a file that is larger than memory to rule out caching. There is no delay when clicking Cancel. In fact, the incomplete destination file is removed the second you click on the button. I suggest to test with recent versions of KDE and Qt software before I reassign. Debian stable is already outdated on arrival, because of the long freezing phase. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 419266] Copying file continues for 8 seconds after canceled
https://bugs.kde.org/show_bug.cgi?id=419266 --- Comment #5 from goo --- You were right, Dolphin also shows the same symptoms. So this is a bug in KIO? -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 419266] Copying file continues for 8 seconds after canceled
https://bugs.kde.org/show_bug.cgi?id=419266 --- Comment #4 from Christoph Feck --- The problem might also be that you aren't using Plasma, so you only get a fallback dialog, which KDE developers rarely test. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 419266] Copying file continues for 8 seconds after canceled
https://bugs.kde.org/show_bug.cgi?id=419266 --- Comment #3 from Christoph Feck --- Could you compare with Dolphin? Both should use KIO. I am not sure if Krusader has a separate copy dialog, or if you are just clicking into the standard KIO progress notifications. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 419266] Copying file continues for 8 seconds after canceled
https://bugs.kde.org/show_bug.cgi?id=419266 --- Comment #2 from goo --- The problem is not the delay because of filling and reading the buffer or the process stucking at 100%, but when you click "Cancel" the copying process continues for a very long time of 8 seconds. In other file managers I know when you click "Cancel" the copying process is stopped immediately and does not continue for such a long time. Also when you run "cp" command line and press "Ctrl-C" the process stops immediately. This is the expected behaviour when canceling a copying proccess. Just try it with the standard file manager of you system. When you click "Cancel" the copying process stops immediately but in the latest version of Krusader the copying process continues for up to 8 seconds as you can see the file size growing for 8 seconds after you clicked "Cancel". On the other hand when you click "Pause" in Krusader the copying process stops immediately. So one way to solve this issue might be to implement pausing the copying process before canceling it. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 419266] Copying file continues for 8 seconds after canceled
https://bugs.kde.org/show_bug.cgi?id=419266 Davide Gianforte changed: What|Removed |Added Status|REPORTED|RESOLVED CC||dav...@gengisdave.org Resolution|--- |NOT A BUG --- Comment #1 from Davide Gianforte --- In Linux, file copies (really, all files) are handled through a memory buffer. When you start a copy, you should see a fast progress because it is filling the buffer and when it is filled, the real write starts. Using a system monitor (e.g. KSysGuard, htop) you can see a memory drop when the copy ends, meaning that the buffer was freed. For the same reason, if you copy a file over a network share you also see that the traffic starts a bit after. Almost all systems, like KIO which is used by Krusader, show the percentage of data sent to the buffer and it seems that the copy stucks at 100% because the buffer size is yet to be written on disk. -- You are receiving this mail because: You are watching all bug changes.
