Community
Participate
Working Groups
Build Identifier: M20110210-1200 Renaming a Java file causes "Resource is out of sync with the file system". I rename a file with F2 in the Package Explorer view. The file does get renamed, and references to the new class (it seems) get updated. The class name inside the file is not changed, I get the error instead. Reproducible: Always Steps to Reproduce: 1. Select a Java file in the Package Explorer 2. Press F2 to rename 3. The file is renamed, but before the class name inside the file is updated, renaming aborts with "Resource is out of sync with the file system". Oh, and just to be sure, I tried pressing F5 and/or selecting Refresh in the Package Explorer just before renaming.
Stack trace: org.eclipse.core.internal.resources.ResourceException: Resource is out of sync with the file system: '/AndroMail/src/org/kman/AndroMail/mail/MessageHeaderCollector.java'. at org.eclipse.core.internal.localstore.FileSystemResourceManager.write(FileSystemResourceManager.java:976) at org.eclipse.core.internal.resources.File.internalSetContents(File.java:325) at org.eclipse.core.internal.resources.File.setContents(File.java:364) at org.eclipse.jdt.internal.core.Buffer.save(Buffer.java:383) at org.eclipse.jdt.internal.core.Openable.save(Openable.java:481) at org.eclipse.jdt.internal.core.CompilationUnit.save(CompilationUnit.java:1290) at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.saveContent(CopyResourceElementsOperation.java:602) at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processCompilationUnitResource(CopyResourceElementsOperation.java:350) at org.eclipse.jdt.internal.core.CopyResourceElementsOperation.processElement(CopyResourceElementsOperation.java:399) 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.CompilationUnit.rename(CompilationUnit.java:1264) at org.eclipse.jdt.internal.corext.refactoring.changes.RenameCompilationUnitChange.doRename(RenameCompilationUnitChange.java:59) 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) Session data: eclipse.buildId=M20110210-1200 java.version=1.6.0_24 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=ru_RU Framework arguments: -product org.eclipse.epp.package.java.product Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.java.product
I could not reproduce this using a standalone testcase, with or without references to the class in question (build I20110301-1537). Can you please attach a reproducible testcase? thanks!
(In reply to comment #2) > I could not reproduce this using a standalone testcase, with or without > references to the class in question (build I20110301-1537). > Can you please attach a reproducible testcase? thanks! Caused by Mercurial TortoiseHG 2.02 in combination with MercurialEclipse 1.7.1. Sorry about this, will refer the bug to MercurialEclipse.
Then closing as WORKSFORME
Reopen to close as NOT_ECLIPSE.
Closed.
Verified for 3.7M7
Is there a workaround known for this bug? Is this issue identical or not related to this bug? http://stackoverflow.com/q/23655990/1184842
