Bug 241932 - Destination file is not removed when file copy is aborted
Summary: Destination file is not removed when file copy is aborted
Status: RESOLVED DUPLICATE of bug 148429
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-16 22:52 UTC by Matt
Modified: 2013-06-18 05:22 UTC (History)
3 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 Matt 2010-06-16 22:52:16 UTC
Version:           unspecified (using KDE 4.3.5) 
OS:                Linux

If you have a file that you are copying, and during the copy you click the
cancel button, the destination file is not removed. The file is useless since
it's incomplete and should be removed. The user is left to remove the file
manually and, if they don't know that, they can have many incomplete files
laying around causing confusion.

Reproducible: Always

Steps to Reproduce:
1. Copy a file big enough to see the progress bar
2. Click the cancel button before the copy is done

Actual Results:  
The incomplete destination file is still there.

Expected Results:  
It's expected that the incomplete file should be removed since the copy did not
complete. The computer needs to clean up after itself.
Comment 1 RussianNeuroMancer 2011-02-14 12:45:55 UTC
There is already filed bug about this problem: https://bugs.kde.org/show_bug.cgi?id=148429
Comment 2 Matt 2011-02-14 18:02:13 UTC
(In reply to comment #1)
> There is already filed bug about this problem:
> https://bugs.kde.org/show_bug.cgi?id=148429

That is not the same bug. That bug is asking for something different and far more complicated. What I am asking for is only to bring parity to how OS's work (Windows, Mac OS X and classic).

To summarize: if you are in the middle of a file copy and click cancel, the file that is currently being copied should be deleted from the destination since the copy was aborted before it completed. Any files that successfully completed copying prior to canceling would remain.
Comment 3 RussianNeuroMancer 2011-02-15 02:01:29 UTC
Yes, you are right, I mistake.
But, you know, these are the two issues are related. Because there is two ways:
1. Dolphin remove file when copy is aborted: https://bugs.kde.org/show_bug.cgi?id=241932
2. Dolphin not remove file when copy is aborted, but allow to continue copy process later: https://bugs.kde.org/show_bug.cgi?id=148429
And maybe one another way:
3. Ask user: remove files?

If we follow way 1, then 2 can't be implemented. But if we follow way 3 then issue 1 is solved, and it's possible to implement way 2.

You still choise way 1?
Comment 4 RussianNeuroMancer 2011-02-15 02:04:43 UTC
Ah, sorry. https://bugs.kde.org/show_bug.cgi?id=148429 already include way 3 ("Requested Rollback" for copy process mean ask to remove files).

I think implement https://bugs.kde.org/show_bug.cgi?id=148429 is better idea then just remove files without request.
Comment 5 Asen Lekov 2011-11-25 15:52:04 UTC
Duplicates bug 148429
Comment 6 Dawit Alemayehu 2013-06-18 05:22:59 UTC

*** This bug has been marked as a duplicate of bug 148429 ***