Version: (using KDE KDE 3.5.5) Installed from: SuSE RPMs OS: Linux The Issue: When I copy or move content to a removable drive, it may fill up without the whole being copied. The Mockup and explanations at : http://www.kde-look.org/content/show.php?content=63302 Currently konqueror or dolphin would show an extra dialog with 3 buttons, See 1st Screenshot with Cancel, Skip and AutoSkip. In a disk full state all buttons work similarly (Actually Skip would skip the copy or move till a smaller file which can be copied is obtained, So in general you would be more interested to cancel the operation and try other means like compress it or get some files deleted at destination). In other cases Skipping would result in something you had never wished for. My proposal is to add an extra button Rollback. The rollback would delete the copied items in case of a copy failure leaving the destination unaltered. It would revert back all the files moved in the case of a move. I was thinking to ask for another button Retry like in windows but it may get a bit overcrowded with 5 buttons for the error dialog. Obviously, many users will try again from start so a Continue button is also a good addition. Reference: Bug 29526: Possibility to continue file download if no space left on device with Status:UNCONFIRMED Opened: 2001-07-22 18:18 Kindly give your views.
*** 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.
Duplicate https://bugs.kde.org/show_bug.cgi?id=241932
*** Bug 241932 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 125102 ***