[Win32] Folder becomes a file in the workspace tree when a child is deleted during `refreshLocal` (regression in 2026-09)

Start with Win32Handler.fetchFileInfo and the listDirectoryAndGetFileInfos override, then LocalFile.childInfos and LocalFile.fetchInfo, to see where the name is left unset when a child disappears. Pull request #3025 already targets this, so review it before touching code. Done means the race test RefreshRaceTest no longer yields an empty-name entry and refreshLocal keeps the folder a folder.

Description

Since Eclipse 2026-09 (org.eclipse.core.filesystem 1.11.500), IResource#refreshLocal can turn an existing folder into an IFile in the workspace tree. This happens when one of the folder's children is deleted while the refresh is listing it. On disk the folder is still a directory, but the workspace treats it as a file. After that, creating anything below it fails:

org.eclipse.core.internal.resources.ResourceException: Resource '/P/work' does not exist.
        at org.eclipse.core.internal.resources.Resource.checkExists
        at org.eclipse.core.internal.resources.Folder.assertCreateRequirements
        at org.eclipse.core.internal.resources.Folder.create

If the race happens directly below the project, AssertionFailedException: Path must include project and resource name is thrown instead.

With auto-refresh enabled, the refresh monitor usually turns the file back into a folder (fileToFolder) a little later. That makes the failure flaky.

Root cause

1. LocalFile.childInfos() now goes through LocalFileNativesManager.listDirectoryAndGetFileInfos → NativeHandler.listDirectoryAndGetFileInfos (introduced in #2787). It gets the names from File.list() and then calls fetchFileInfo(dir + File.separator + name) for each one.
2. If a child is deleted between File.list() and the native lookup, Win32Handler.fetchFileInfo (FindFirstFileW → ERROR_FILE_NOT_FOUND) returns a FileInfo with an empty name, exists=false and no error code. Unlike the old code path (FileStore.childInfos → LocalFile.fetchInfo), the name is never filled in.
3. During refreshLocal:
   • UnifiedTree.getLocalList sorts the "" entry first.
   • createChildNodeFromFileSystem appends "" to the parent path, which produces a file node at the folder's own path.
   • RefreshLocalVisitor.synchronizeExistence sees a gender variant, and synchronizeGender calls folderToFile.

The Win32Handler override of listDirectoryAndGetFileInfos added in #2952 has the same flaw: it also leaves the name unset on NoSuchFileException.

Suggested fix

The other implementations of NativeHandler.fetchFileInfo(String) all seem to ensure that the returned fileinfo has a filename set, only the Win32Handler does not seem to have such a case and relies on the callers of fetchFileInfo (e.g. LocalFile.fetchInfo(int, IProgressMonitor) to fix this. So maybe we should also make sure the Win32Handler always sets name?

Steps to reproduce

Windows only. The following JUnit 5 test fails reliably within the first few attempts. Test 1 checks the filesystem layer only. Test 2 shows the symptom through the Workspace API.

package org.eclipse.core.tests.filesystem;

import java.nio.file.Files;
import java.nio.file.Path;
import java.util.ArrayList;
import java.util.List;
import org.eclipse.core.filesystem.EFS;
import org.eclipse.core.filesystem.IFileInfo;
import org.eclipse.core.filesystem.IFileStore;
import org.eclipse.core.resources.IFolder;
import org.eclipse.core.resources.IProject;
import org.eclipse.core.resources.IResource;
import org.eclipse.core.resources.ResourcesPlugin;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.preferences.IEclipsePreferences;
import org.eclipse.core.runtime.preferences.InstanceScope;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;

class RefreshRaceTest {

    @TempDir
	Path tempDir;

	IProject project;

    @AfterEach
	void afterEach() throws Exception {
        if (project != null) {
            project.delete(true, true, null);
            setAutoRefresh(true);
        }
    }

	@Test
    void childInfosNeverReturnsNamelessEntry() throws Exception {
		IFileStore store = EFS.getLocalFileSystem().getStore(tempDir.toUri());
        race(tempDir, () -> {
			for (IFileInfo info : store.childInfos(EFS.NONE, null)) {
				Assertions.assertFalse(info.getName().isEmpty(), "entry with empty name: " + info);
            }
        });
    }

    @Test
    void refreshLocalKeepsFolderAFolder() throws Exception {
		setAutoRefresh(false); // the refresh monitor would undo the damage
		project = ResourcesPlugin.getWorkspace().getRoot().getProject("P");
        project.create(null);
        project.open(null);
		IFolder folder = project.getFolder("work");
        folder.create(true, true, null);

        race(folder.getLocation().toPath(), () -> {
            project.refreshLocal(IResource.DEPTH_INFINITE, null);
			Assertions.assertInstanceOf(IFolder.class, project.findMember("work"));
        });
        folder.getFolder("data").create(true, true, null);
    }

	/** Fills dir with files and runs probe while another thread deletes them. */
	static void race(Path dir, Probe probe) throws Exception {
		for (int attempt = 0; attempt < 20; attempt++) {
			List<Path> files = new ArrayList<>();
			for (int i = 0; i < 2000; i++) {
                files.add(Files.createFile(dir.resolve("file" + i + ".tmp")));
            }
			Thread deleter = new Thread(() -> files.forEach(f -> f.toFile().delete()));
            deleter.start();
			while (deleter.isAlive()) {
				probe.run();
            }
			deleter.join();
        }
    }

	static void setAutoRefresh(boolean value) throws Exception {
		IEclipsePreferences prefs = InstanceScope.INSTANCE.getNode(ResourcesPlugin.PI_RESOURCES);
        prefs.putBoolean(ResourcesPlugin.PREF_AUTO_REFRESH, value);
        prefs.flush();
    }

	interface Probe {
        void run() throws CoreException;
    }
}

Failures observed:

entry with empty name: FileInfo [name=, length=0, lastModified=0, exists=false, attributes=12582912, errorCode=0]
expected: <org.eclipse.core.resources.IFolder> but was: <org.eclipse.core.internal.resources.File>

Disclaimer: I had Claude write this up but debugged most of it manually.
Overall I think that the temporary corruption of the resource tree is a quite a nasty bug.
/cc @HannesWell @iloveeclipse