[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786515#comment-17786515
]
Tamas Cservenak commented on MRESOLVER-372:
-------------------------------------------
The more I read about the issue "atomic file move on windows" (and related) am
more and more inclined to say that "atomic move" on Windows is like Russian
roulette: sometimes it works, sometimes not.
The strange thing to me is this: in local repository, release artifacts are
immutable, snapshots are also (sans the "snapshot normalization" also reported,
but that can be tuned in resolver, see config), and the per-definitionem
mutable files are metadata files, but NOBODY reported this issue for metadata
files! (one possible reason: they are not kept open by IDEs, but are "one time
read" and processed, most probably).
Other thing: this is NOT in whatsoever relation to "locking" introduced in
1.9.x, actually to me this seems totally unrelated to it. Resolver does NOT
lock artifact files (!), it does use "parallel hierarchy" to implement "mutual
exclusive advisory locking" (so other mvn 3.9 will go for those "parallel"
paths and mutually exclude).
This is all about "atomic move" Java support on Windows, as related code have
only one change: old resolver (1.8 and before) did the good old "copy+delete
src" using pre-nio2, while resolver 1.9 insist on "Files.move(atomic)" but the
only reason for that is to prevent other processes to read partially written
files....
Am still looking, but anyone having any idea, shoot!
> 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)
