slachiewicz opened a new pull request, #2284: URL: https://github.com/apache/maven-resolver/pull/2284
Fixes #2269. Since 1.9.25 `DefaultTrackingFileManager.delete()` unlinks the `.lastUpdated` file while it still holds the file's channel and exclusive lock. A Linux NFS client answers that with `EBUSY`, and because the method rethrows as `UncheckedIOException`, the first successful download on an NFS-hosted local repository fails the build. The lock is still taken, because it is what serialises this process with another Maven updating the same file, but it is released and the channel closed before `Files.delete`. The window between unlock and unlink is the one the code had before 1.9.25, when `touchFile.delete()` ran without any lock at all. The failure semantics stay as they are, aligned with `NamedLocksTrackingFileManager` on master. No new test: there is no portable way to make unlinking an open file fail, and the existing `testDeleteFileIsGone` covers the success path on every platform CI runs. Verified: `mvn -pl maven-resolver-impl -am verify` on JDK 21 → BUILD SUCCESS, checkstyle included, `DefaultTrackingFileManagerTest` 6/0/0. Master port: #PLACEHOLDER. -- 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]
