| Summary: | Requested Rollback and Continue in Copy / Move dialog | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Manik Chand Patnaik <mcpatnaik> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | bugreports, kdelibs-bugs, meven29, MurzNN, nate, nzlbob2332, sreich |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Manik Chand Patnaik
2007-08-01 19:32:04 UTC
*** This bug has been confirmed by popular vote. *** Hm, I wonder.. .what actually happens when you cancel say... a normal transfer that is going on. Do the files become removed, or do they stay? Hi, Thanks Shaun for taking interest. Let me explain, Scenario 1) When copied:- let's presume that a transaction is initiated for it. So the logical outcome is to rollback the copy process. But what is rollback in copy? clean incomplete copy process by deleting already copied files. Here we may request the user to choose (Keep already copied items or Clean copied items). Scenario 2) When moved:- The same transaction method will logically point to rollback all items already moved to the state before move started. The same suggestion for copy is also applicable here. Please bounce back your thoughts. I do like this idea actually, but what is the current functionality? Sometimes it may come in handy when you have to shutdown or eject a device while transferring, but want to resume it, I have had this happen before.... Does the current way automatically delete them when it is cancelled? Thanks for the situational layout. I'm not sure if this changed in KDE4 or no.. I will have to check also, but tell me none-the-less as I am curious to know if the functionality has changed also. Please upgrade to KDE4, it's awesome ;-) Well, we do have "Undo" support already; this is mostly a request for calling Undo from the dialog itself, isn't it? Yeah, it seems like it, unless in the case that you cancel, it _automatically_ rolls it back, which I am thinking may happen, but haven't tried it. But that would be the only useful case for this. Hi, The concept is to provide the undo in the dialog and more. 1. Undo will happen only after the current job is done. So our requirement is when the job is continuing there should be options available. 2. The origin of the suggestion is rooted in a scene where the destination fills up and the user is weary of an incomplete copy or move. In my opinion, a partial copy and partial move is the least logical choice. Retry and Rollback should be the most logical choices. 3. The user should be given an opportunity to free up space at destination and retry because copy and move of large quantity takes time and redoing all from start does not make sense. 4. Skip as a solution good only when there is problem in reading or in a case when we need to fit in smaller files at the destination by skipping larger files. 5. After the job is done, it is straight forward to undo an operation but it is less critical than providing a facility for undo when the job is running and facing problems and the user needs to take action then and there. Currently you can skip larger files, cannot retry, cannot rollback when a copy or move job is waiting user action. So the use-case is different in concept, not at all the same to undo. Mr. Shaun, I use 4.2 now. Please comment. *** Bug 241932 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of bug 125102 *** |