Bugzilla – Full Text Bug Listing
| Summary: | [rename] Undo of a failed package rename operation doesn't work - Was (JavaModelException during package name refactoring when some files contain errors) | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ulli Hafner <Knut.Friedhelm> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | amj87.iitr, deepakazad, jarthana, markus.kell.r, satyam.kandula, verawahler |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
|
Description
Ulli Hafner
Ulli, this may be due to the java files with compilation errors. You can do the refactoring once the errors are resolved and you won't get the exception. Jay, this seems like the expected behaviour looking at the code. Can you check? Thanks! Seems to be unrelated to the compile errors. After fixing the errors I tried again an got the same exception: eclipse.buildId=M20110210-1200 java.version=1.6.0_24 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Framework arguments: --launcher.XXMaxPermSize=256m Command-line arguments: -os linux -ws gtk -arch x86 -debug /home/hafner/Documents/eclipse.debug -data /home/hafner/Workspaces/Hudson --launcher.XXMaxPermSize=256m Error Wed Apr 13 09:44:58 CEST 2011 Internal Error Java Model Exception: Core Exception [code 4] Problems encountered while moving resources. at org.eclipse.jdt.internal.core.MultiOperation.processElements(MultiOperation.java:175) at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processElements(CopyResourceElementsOperation.java:417) at org.eclipse.jdt.internal.core.MultiOperation.executeOperation(MultiOperation.java:90) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793) at org.eclipse.jdt.internal.core.JavaModel.rename(JavaModel.java:285) at org.eclipse.jdt.internal.core.PackageFragment.rename(PackageFragment.java:432) at org.eclipse.jdt.internal.corext.refactoring.changes.RenamePackageChange.renamePackage(RenamePackageChange.java:207) at org.eclipse.jdt.internal.corext.refactoring.changes.RenamePackageChange.doRename(RenamePackageChange.java:136) at org.eclipse.jdt.internal.corext.refactoring.AbstractJavaElementRenameChange.perform(AbstractJavaElementRenameChange.java:86) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.access$0(DynamicValidationStateChange.java:1) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange$1.run(DynamicValidationStateChange.java:98) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4777) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.perform(DynamicValidationStateChange.java:101) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278) at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:258) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306) at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:218) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Caused by: org.eclipse.core.internal.resources.ResourceException: Problems encountered while moving resources. at org.eclipse.core.internal.resources.Resource.move(Resource.java:1609) at org.eclipse.core.internal.resources.Resource.move(Resource.java:1558) at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processPackageFragmentResource(CopyResourceElementsOperation.java:468) at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processElement(CopyResourceElementsOperation.java:403) at org.eclipse.jdt.internal.core.MultiOperation.processElements(MultiOperation.java:163) ... 27 more Caused by: org.eclipse.core.internal.resources.ResourceException: Problems encountered while moving resources. at org.eclipse.core.internal.resources.Resource.move(Resource.java:1609) at org.eclipse.core.internal.resources.Resource.move(Resource.java:1558) at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processPackageFragmentResource(CopyResourceElementsOperation.java:468) at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processElement(CopyResourceElementsOperation.java:403) at org.eclipse.jdt.internal.core.MultiOperation.processElements(MultiOperation.java:163) at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processElements(CopyResourceElementsOperation.java:417) at org.eclipse.jdt.internal.core.MultiOperation.executeOperation(MultiOperation.java:90) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793) at org.eclipse.jdt.internal.core.JavaModel.rename(JavaModel.java:285) at org.eclipse.jdt.internal.core.PackageFragment.rename(PackageFragment.java:432) at org.eclipse.jdt.internal.corext.refactoring.changes.RenamePackageChange.renamePackage(RenamePackageChange.java:207) at org.eclipse.jdt.internal.corext.refactoring.changes.RenamePackageChange.doRename(RenamePackageChange.java:136) at org.eclipse.jdt.internal.corext.refactoring.AbstractJavaElementRenameChange.perform(AbstractJavaElementRenameChange.java:86) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.access$0(DynamicValidationStateChange.java:1) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange$1.run(DynamicValidationStateChange.java:98) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4777) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.perform(DynamicValidationStateChange.java:101) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278) at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:258) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306) at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:218) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Contains: Error updating cache during move/delete. The resource cannot be moved, renamed or deleted due to an internal error. It'll help if you can attach a reproducible test case or your workspace for us to investigate. Thanks. I can't reproduce the bug, either. There must be something about the resources in the particular package that are being moved. If you can isolate the problem and share it with us, it would help. I'll try to track down that problem and will attach my workspace. Anyway, the 'Abort'/'Undo' dialog never worked for me if there was an exception. Can you at least reproduce that problem? (In reply to comment #5) > Anyway, the 'Abort'/'Undo' dialog never worked for me if there was an > exception. Can you at least reproduce that problem? I have seen it working (though in different scenarios). (In reply to comment #5) > I'll try to track down that problem and will attach my workspace. If you are still facing this issue, could you attach your affected workspace. I tried again and can't reproduce the bug. Without being able to reproduce, we can't do much here. I am able to reproduce the problem on windows by actually keeping a file in the package opened outside Eclipse. It is natural to expect the move to fail in these conditions. By looking at the call stack, it is move that has failed. However, the user says that all the files are moved but the folder move didn't happen. I cannot speculate the reasons for the failure of the move. One reason I could think of is the underlying SCM is causing the move to fail. Ulli, What SCM are you using? With the above steps, I could also reproduce the 'Undo' not working. The 'move' problem is probably not something that we need to fix, but I think we should fix the 'Undo' problem. So, I am reopening. Changed the summary as per the problem that needs to be fixed. Please Look at comment 8 for more details. I'm using git as SCM. I also noticed the undo problem using Windows and subversion plug-in. Very often an exception occurs between an rename package refactoring. Then the undo dialog is presented with both options not working... I managed to reproduce this. But unfortuntely there may not be much we can do here. But whatever the fix is, it has to be done in the JDT/UI. I looked at the code for some time and this is what my investigation shows: The CompositeChange#handleUndos() looks for the undo change via getUndoUntilException, but it does so only when the change is a CompositeChange. But unfortunately the RenamePackageChange, with which we are dealing here, is not one and no effort is made to undo the changes thus far. Now the fix could be as simple as making the RenamePackageChange a CompositeChange, but it is already a ResourceChange. So, either the hierarchy has to be modifies or an alternate fix has to be found out. Moving to JDT/UI for further investigation. (In reply to comment #11) > I managed to reproduce this. Reproduce what? - What Satyam mentions in comment 8? - Or the original bug report? If it was the second can you please provide the steps to reproduce. (In reply to comment #12) > Reproduce what? > - What Satyam mentions in comment 8? > - Or the original bug report? > If it was the second can you please provide the steps to reproduce. I was particularly talking about the failing 'undo' even though I can reproduce both by just opening the package being renamed in a command prompt - I used a git shell. Of course, we can't do anything about the failing rename action. But we should try and see if the undo can be fixed. The only way we could fix this is by implementing RenamePackageChange manually without using IPackageFragment#rename(..). I can reproduce similar errors by keeping a *.txt file open in Lotus Symphony or by having a cmd.exe prompt with the package's folder as current directory. Ulli: Your stacktraces contain "Contains: Error updating cache during move/delete.". I didn't find this message in the Eclipse SDK, but it looks like it's coming from org.eclipse.egit.core.GitMoveDeleteHook. Please file a new bug for EGit/Core if you have more information about when this happens. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |