[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786702#comment-17786702
]
Tamas Cservenak commented on MRESOLVER-372:
-------------------------------------------
So, just to recap:
* this has nothing to do with locking (we do not lock artifact or metadata
files)
* Pre 1.9 resolver did the very same thing, no change in this area (it also
normalized snapshots and replaced files on download/install).
* The ONLY change in this respect Resolver 1.9 did is change the move operation
implementation from pre-nio2 (as it was in 1.8) to nio2 + atomic (1.9).
So, my guts are telling me that the culprit is "atomic" on Windows. The reason
for atomic is to prevent partially written files being read by some other
process (ie IDE).
Also, according to that above, Resolver 1.8 was also normalizing snapshots and
was rewriting files (if existing) on install/resolve, hence very same problems
would be reported against it as well, but are not.
Hence, I am pretty sure it is "atomic" that is the culrpit of this issue...
Please test the PR.
> Download fails if file is currently in use under windows
> --------------------------------------------------------
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Reporter: Christoph Läubrich
> Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> 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{code}
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
