Cannot rename folders using the Project Explorer view

[acarstoiu]

I'm using the latest Eclipse Platform 4.34.0.I20241120-1800 with Git integration for Eclipse 7.1.0.202411261347-r (notice the final "-r" 🧐).

Steps to reproduce

In the Project Explorer view, choose a folder and try to rename it. The operation has no effect, that is, the folder's name remains the same.

I suspect the operation actually takes place, but is somehow immediatelly reverted since it leaves traces in the git status output, with the new folder name appearing in the staged changes list as a bunch of renamed files, but also in the not staged changes list as removed files.

Log output

After trying to rename the connectors folder within a project, the .metadata/.log file reads:

!ENTRY org.eclipse.ltk.ui.refactoring 4 10000 2025-01-16 10:12:52.297
!MESSAGE Internal Error
!STACK 1
org.eclipse.core.internal.resources.ResourceException: Problems encountered while moving resources.
	at org.eclipse.core.internal.resources.Resource.move(Resource.java:1555)
	at org.eclipse.ltk.core.refactoring.resource.RenameResourceChange.perform(RenameResourceChange.java:118)
	at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
	at org.eclipse.ltk.internal.ui.refactoring.actions.RenameResourceHandler.performRename(RenameResourceHandler.java:110)
	at org.eclipse.ltk.internal.ui.refactoring.actions.RenameResourceHandler.execute(RenameResourceHandler.java:58)
	at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:277)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:98)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:299)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:233)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:174)
	at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:165)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:488)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:485)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:204)
	at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommandInContext(LegacyHandlerService.java:436)
	at org.eclipse.ui.internal.ide.actions.LTKLauncher.runCommand(LTKLauncher.java:140)
	at org.eclipse.ui.internal.ide.actions.LTKLauncher.renameResource(LTKLauncher.java:86)
	at org.eclipse.ui.actions.RenameResourceAction.lambda$5(RenameResourceAction.java:550)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:5042)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4522)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1151)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1042)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:663)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:570)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:173)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:178)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:208)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:143)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:109)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:439)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:271)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:668)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:605)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1481)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1454)
Contains: Resource is out of sync with the file system: '/Back-end engine/connectors'.
!SUBENTRY 1 org.eclipse.core.resources 1 4 2025-01-16 10:12:52.297
!MESSAGE Problems encountered while moving resources.
!SUBENTRY 2 org.eclipse.core.resources 1 4 2025-01-16 10:12:52.297
!MESSAGE Resource is out of sync with the file system: '/Back-end engine/connectors'.

Obtained under this environment:

os.arch=amd64
os.name=Linux
os.version=6.12.9-gentoo
java.runtime.name=OpenJDK Runtime Environment
java.runtime.version=21.0.5+11-LTS
java.vendor=Eclipse Adoptium
java.vendor.url=https://adoptium.net/
java.vendor.version=Temurin-21.0.5+11

The JDK binaries are those prebuilt by the Eclipse Adoptium project, not locally built.

[jukzi]

@N1k145 please check if this a regression from eclipse-platform/eclipse.platform.ui#2262

[N1k145]

@jukzi @acarstoiu I don't think this is related.
I have only touched the behaviour of projects, not other resources.

But we have seen this issue already in our RCP product, long before this change was done.

What I am noticing is this line:
!MESSAGE Resource is out of sync with the file system: '/Back-end engine/connectors'.

This happens when there is something which is changeing the resource on file basis and the eclipse resouces is not up to date before the action happens.
This can happen when ether another process or the same process but using Java Files and not Eclipse Resources modifies the file.

I can reproduce the exact same stracktrace when I first rename the folder on the file system and then in eclipse. But this was always the case

[jukzi]

Can not reproduce. Probably some step is missing. Tried to create new folder "x", F2, "y" -> works.

[acarstoiu]

@jukzi Did you try this with the git plugin in use and in the presence of a git repository holding files in folder x?

@N1k145 I do not do anything outside Eclipse when renaming those folders. In Preferences -> General -> Workspace, the "Refresh using native hooks or polling" checkbox is ticked.
I also noticed that Eclipse has a hard time refreshing the subfolders of node_modules/ folders (yes, I'm programming for Node.js), which are actually symlinks created by pnpm.

Forgot to mention that renaming files (as opposed to folders) works.

[N1k145]

@acarstoiu can you describe a bit more about your folder structure, or maybe provide a minimal example project where you have the issue.

Or can you just create a new "default" eclipse project and test if you have the same issue there. I have the feeling that this could be related to your symlinks

I tested the same thing as @jukzi and for this also work's, with enabled git, but I tested in Windows.

[jukzi]

@acarstoiu please describe all the exact steps to reproduce the issue otherwise the issue will be closed.

[acarstoiu]

What I can definitely say is that the problem is surfaced by ticking the "Refresh using native hooks or polling" checkbox in Preferences -> General -> Workspace. It's not enough to un-tick it and choose File -> Restart, you must stop and start again Eclipse.

It has nothing to do with the Git integration for Eclipse plug-in, as folders that are not tracked cannot be renamed either.
I even uninstalled the two heavier plug-ins which I have in my enviroment, just to check for a side-effect - none observed ✅

So, this is a bug showing up in the latest line of Linux kernels (6.12.x), on Gentoo, with the latest Eclipse Adoptium JDK and the latest release of the Eclipse platform when the native hooks (or polling) are employed for refreshing the file system state (the software versions are listed in my first comment ☝️).

Note

While playing around in order to narrow the possible causes, I found a folder that I can rename, within the same project. The difference between it and the others that I can't rename is the fact that it is "fatter", i.e. it contains considerably more files.
This points to a time sensitive issue.

[merks]

I've seen problems like this with the automatic refresh in other contexts. It's really nice that the IDE refreshes automatically, unfortunately it will also do that automatically sometimes in the middle of some ongoing operation leading to hard-to-reproduce, unpredictable problems... ☹

[iloveeclipse]

this is a bug showing up in the latest line of Linux kernels (6.12.x), on Gentoo, with the latest Eclipse Adoptium JDK and the latest release of the Eclipse platform when the native hooks (or polling) are employed for refreshing the file system

I haven't checked the code around but someone (either refactoring code or autorefresh hook code) probably works without taking workspace lock?

[acarstoiu]

Do you mean that Eclipse is taken by surprise by a filesystem change ordered by itself and then tries to revert the operation (in this case a rename)?