gnodet commented on PR #2198: URL: https://github.com/apache/maven-resolver/pull/2198#issuecomment-6130646231
## Interaction with Windows IDE-lock fix (PR #2205) When `hardLink=true` and IntelliJ (or another IDE) has the destination `.jar` open on Windows, `Files.deleteIfExists(dstPath)` inside the try block throws `AccessDeniedException` (a subclass of `IOException`). That is correctly caught and falls back to `pathProcessor.copyWithTimestamp()`. However, `copyWithTimestamp()` internally uses `retryingMove()`, which also fails with `AccessDeniedException` on the same locked target — so by itself, this PR's degradation path still ends with a build failure on Windows+IDE. PR #2205 fixes `retryingMove()` to add a last-resort `classicCopy()` fallback after exhausting all rename attempts. Together the two PRs compose cleanly: hard-link fails → copyWithTimestamp → retryingMove retries → classicCopy fallback → build succeeds. The degradation chain in `hardLink=true` mode on Windows with an IDE lock: 1. `Files.deleteIfExists(dstPath)` → `IOException` (caught ✅) 2. Falls back to `pathProcessor.copyWithTimestamp(srcPath, dstPath)` 3. `retryingMove()` → `AccessDeniedException` × N retries 4. **With PR #2205**: `classicCopy(source, target)` → stream write succeeds ✅ So this PR's fallback degradation is correct but incomplete without #2205. -- 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]
