gnodet commented on code in PR #2205:
URL: https://github.com/apache/maven-resolver/pull/2205#discussion_r4252154789
##########
maven-resolver-spi/src/main/java/org/eclipse/aether/spi/io/PathProcessorSupport.java:
##########
@@ -71,6 +76,18 @@ public class PathProcessorSupport implements PathProcessor {
protected static final long WINDOWS_MOVE_RETRY_DELAY =
Long.getLong(PathProcessor.class.getName() +
"WINDOWS_MOVE_RETRY_DELAY", 50L);
+ /**
+ * Whether to fall back to a direct (non-atomic) stream copy when all
rename attempts on Windows are exhausted
+ * with {@link AccessDeniedException} due to a persistent file lock (for
example an IDE holding the target
+ * {@code .jar} open). When {@code true} (the default), the installer
degrades gracefully to the pre-2.0.24
+ * behavior — the target is overwritten in-place via a stream, which on
Windows succeeds even if another
+ * process holds a shared read handle. The atomicity guarantee is lost for
this last-resort path, but the
Review Comment:
The concern is valid for the general case, but the code already constrains
the fallback to a narrow last-resort path that does not truncate a
partially-written file:
1. **The fallback only triggers on Windows**, guarded by `IS_WINDOWS` before
`retryingMove` is called.
2. **The fallback only triggers when all atomic-rename attempts are
exhausted with `AccessDeniedException`** — meaning the *source* temp file is
complete and fully written; only the final rename step is failing because the
*target* is locked by another process (e.g. IDE).
3. **`classicCopy` reads from the fully-written temp file** and streams it
over the locked target. The source is intact; it is not a partial write.
The "partially written artifact" scenario Copilot describes would require
the source temp file itself to be incomplete, which cannot happen here — the
temp file is finalized before `move()`/`close()` is called.
The true integrity risk (concurrent reader seeing mid-write state) exists
but is bounded to the final stream-copy window on a file already being
continuously held open by the IDE. This is an accepted trade-off for the
fallback-enabled path, documented in the field Javadoc and the warning log.
Users who need strict atomicity can set
`-D...WINDOWS_CLASSIC_COPY_FALLBACK=false`.
--
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]
