slachiewicz opened a new pull request, #2124: URL: https://github.com/apache/maven-resolver/pull/2124
Ports the Windows part of #2083 to the 1.9.x line. On `master` the final move lives in `PathProcessorSupport`; 1.9.x has no such class and the live path is `FileUtils.CollocatedTempFile.close()` in `maven-resolver-util`, so this is a reimplementation. On Windows, `close()` previously opened the target path with a truncating stream and copied the temp file into it. Between the truncation and the last write, a concurrent reader (a forked JVM resolving the same artifact, for example) sees a short file at the final path, and a process killed in that window leaves it there. The temp file is collocated with the target, so the move is now a rename with `REPLACE_EXISTING` and `ATOMIC_MOVE`, retried a bounded number of times because sharing violations from virus scanners, indexers and readers are transient on Windows. The attempt count and delay are tunable through the `org.eclipse.aether.util.FileUtils.windowsMoveAttempts` and `windowsMoveRetryDelay` system properties (defaults 5 and 50 ms). Non-Windows platforms are unchanged. Behavior change to note for Windows: replacing a file another process holds open now fails after the retries instead of truncating it in place. That is the same trade `master` made. The new `FileUtilsTest` covers the rename replacing, creating, and leaving the target alone when the source is missing, plus `writeFile` end to end. I ran it on macOS; the Windows job in CI is the run that matters. Verified: `mvn -pl maven-resolver-util -am verify` -> BUILD SUCCESS, 280 tests in the module, 0 failures; `spotless:apply` produced no further changes. *This change was created with AI assistance.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
