Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Preambulum: original issue is not related to locking at all, is about change done in 1.9 where file processor was altered to use nio2 atomic move. Reason was to prevent possibility of partial download being read by other process (and prevent incomplete files in case of crash). Seems windows (or java on windows) have issues with atomic fs ops, causing sporadic (still unsure why) AccessDeniedExceptions. Below is original issue description as reported:
Caused by: java.nio.file.AccessDeniedException: xxx-SNAPSHOT.jar.15463549870494779429.tmp -> xxxx-SNAPSHOT.jar at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103) at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317) at java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293) at java.base/java.nio.file.Files.move(Files.java:1432) at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108) at org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96) at org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490) ... 30 more
My suggestion would be that resolver simply uses the temp file if it can't be moved to final location and marks it as delete on exit. Even though this is not optimal, it at least ensures the the build does not fail to the cost that next time the file needs to be downloaded again.
Attachments
Issue Links
- is related to
-
-
- Open
-
-
-
- Closed
-
- links to