Community
Participate
Working Groups
When using the Project Explorer, a file copy cannot be undone. It seems that the Resource Operation is being executed without an IOperationHistory (which would provide the undo functionality). Providing undo here doesn't seem like it'd be too difficult of a task. Comparing MoveProjectAction's performMove to CopyFilesAndFoldersOperation's performCopy, it seems that MoveProjectAction is executing the operation like so: PlatformUI.getWorkbench().getOperationSupport() .getOperationHistory().execute(op1, monitor, WorkspaceUndoUtil.getUIInfoAdapter(shellProvider.getShell())); And CopyFilesAndFoldersOperation is executing the operation by doing: op.execute(monitor, WorkspaceUndoUtil.getUIInfoAdapter(messageShell)); Not only would this fix benefit the IDE from a UX standpoint, but it'd also benefit RCP application's who reuse the copy action from Platform. If this is desired, I can provide a Gerrit :)
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/167150
Ahh I guess I ignored the big comment: "If we are copying files and folders, do not execute the operation in the undo history, since the creation of a new file is not added to undo history and modification of a file is not added to the same undo history and therefore a redo cannot be properly done. Just execute it directly so it won't be added to the undo history." Maybe there's still a way to either fix the underlying issue ("creation of a new file is not added to undo history and modification of a file is not added to the same undo history"). Or still provide API for those who want to provide undo/redo in their RCP applications In my quick testing.. I didn't seem to find any issues with undo/redo for copying files and folders, so that might be promising.
Does anyone have an opinion or comment regarding this topic? Ideally, I'd like to allow undo/redo of copy resources in the IDE. However, I could settle for adding new API to perform a copy resource action that is undoable.
(In reply to Andrew Obuchowicz from comment #3) > Does anyone have an opinion or comment regarding this topic? No opinion, patch looks OK to me, just ensure that undo / redo works and remove the comment if it does.
So it seems undo/redo was disabled for copy resource actions in Bug 460698. The issue of that bug was that a user could modify a file after having copied it, then undo the copy action from the project explorer and loose all local changes to the copy. This issue still exists, and is sadly a blocker ): Perhaps there's some way to attach a document listener that will remove the undo operation from the stack if the document was modified? Or perhaps the undo/redo implementation of CopyResourcesOperation needs to be improved to account for this case.
In CopyResourcesOperation.computeUndoableStatus, we might be able to check if the target resources modification timestamp has changed which would indicate the user modified the copied resource and the undo shouldn't be allowed.
