Fix sporadic failure in MarkerTest.testMarkerDeltasMoveFile

[Copilot]

Two sequential IFile.move() calls left a window between operations where background jobs (charset/encoding validation) could acquire the workspace lock, fire resource change events against subFile, and cause the listener to record 2 marker deltas for /MyProject/folder/subFile.txt instead of the expected 1 — resulting in a sporadic assertion failure.

Fix

Wrap both moves in a single IWorkspaceRunnable to hold the workspace lock across both operations, preventing background jobs from interleaving and ensuring a single coalesced event with exactly the 4 expected changes:

// Before: two separate calls left a race window
file.move(destFile.getFullPath(), IResource.FORCE, createTestMonitor());
subFile.move(destSubFile.getFullPath(), IResource.FORCE, createTestMonitor());

// After: atomic operation, no interleaving possible
getWorkspace().run(monitor -> {
    file.move(destFile.getFullPath(), IResource.FORCE, monitor);
    subFile.move(destSubFile.getFullPath(), IResource.FORCE, monitor);
}, createTestMonitor());

Reproducing the race (before fix)

for i in $(seq 1 200); do
  mvn -pl resources/tests/org.eclipse.core.tests.resources \
      -Pbuild-individual-bundles \
      -Dtest=MarkerTest#testMarkerDeltasMoveFile \
      verify || { echo "FAILED on run $i"; break; }
done

The failure should manifest within ~200 iterations; with the fix all 200 should pass.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Sporadic fail in MarkerTest.testMarkerDeltasMoveFile</issue_title>
<issue_description>Seen in: https://download.eclipse.org/eclipse/downloads/drops4/I20260313-0720/reports.html#tests

https://download.eclipse.org/eclipse/downloads/drops4/I20260313-0720/testresults/html/org.eclipse.core.tests.resources_ep440I-unit-macosx-x86_64-java21_macosx.cocoa.x86_64_21.html

	[number of markers for resource /MyProject/folder/subFile.txt] expected: 2 but was: 1

org.opentest4j.AssertionFailedError: [number of markers for resource /MyProject/folder/subFile.txt]
expected: 2
but was: 1
at org.eclipse.core.tests.resources.MarkersChangeListener.assertChanges(MarkersChangeListener.java:52)
at org.eclipse.core.tests.resources.MarkerTest.testMarkerDeltasMoveFile(MarkerTest.java:985)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) 

Nothing in the workspace log: https://download.eclipse.org/eclipse/downloads/drops4/I20260313-0720/testresults/ep440I-unit-macosx-x86_64-java21_macosx.cocoa.x86_64_21/org.eclipse.core.tests.resources.AutomatedResourceTests.txt

!ENTRY org.eclipse.core.tests.resources 1 0 2026-03-13 12:50:21.714
!MESSAGE [MarkerTest.testMarkerDeltasMoveFile] setUp

!ENTRY org.eclipse.core.tests.resources 1 0 2026-03-13 12:50:26.760
!MESSAGE [MarkerTest.testMarkerDeltasMoveFile] tearDown
```</issue_description>

<agent_instructions>This is a flaky test so after fixing it, also provide instructions on how to let it run several times. Ideally, the test would fail every X amount of executions (e.g. every 100 executions) and therefore running the test 200 times should let it fail. After the fix, running it 200 times shouldn't fail, not even once.</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes Sporadic fail in MarkerTest.testMarkerDeltasMoveFile #2569

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[fedejeanne]

@copilot are there more occurrences of this problematic pattern (moving files in separate workspace operations) through out the code that need to be looked into? If there are only a few (say 5 to 10) then prepare one draft PRs for those too and also specify how to make them fail so that we can make sure they are really problematic (I don't want to fix what isn't broken).

Does this pattern repeat outside of test code too? How bad is it if this error happens in production? Give examples of possible repercussions of this error (something that can be seen in the UI?)

[Copilot]

@copilot are there more occurrences of this problematic pattern (moving files in separate workspace operations) through out the code that need to be looked into? If there are only a ...

After a thorough search of the test and production codebase:

Other occurrences in test code?

No other test in the repository has the same problematic combination: multiple sequential IResource.move() calls + a MarkersChangeListener asserting delta counts + not wrapped in IWorkspaceRunnable. testMarkerDeltasMoveFile was the only instance. (testMarkerDeltasMoveFolder and testMarkerDeltasMoveProject are unaffected: the former performs only a single folder move, the latter wraps everything in a getWorkspace().run().)

Does the pattern appear in production code?

No. Every place in production code that performs multiple resource moves either:

• Uses IWorkspace.move(IResource[], IPath, ...) (Workspace.java:2152), which internally batches all moves under a single beginOperation/endOperation lock, or
• Is already inside an IWorkspaceRunnable.

So there is no production code at risk.

What would happen in production if the bug existed?

If production code did multiple sequential resource moves without atomicity, resource change listeners would receive one event per move rather than a single coalesced event. Between events, the workspace is in a partially-moved state. Concrete UI consequences:

1. Problems view flicker: An incremental Java build triggered between two moves could report spurious compilation errors (e.g., "cannot resolve import X") that vanish after the second move completes — the user would see temporary red markers.
2. Markers view inconsistency: Markers (e.g., task markers, bookmarks) on the first moved file would appear at their new location while the second file's markers are still at the original location — for a brief moment the Markers view shows an inconsistent state.
3. Team provider misreporting: VCS (e.g., EGit) listeners tracking resource changes could receive incomplete information and incorrectly report one file as "moved" and the other as "deleted + added" instead of both as "moved".