[ https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787033#comment-17787033 ]
ASF GitHub Bot commented on MRESOLVER-372: ------------------------------------------ laeubi commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815784844 @cstamas I'm a bit late to the party **but** as @rdicroce already tested showed I cna only tell that Maven 3.8.x ("old"? resolver) has worked under Windows why upgrade to 3.9.x ("new"? resolver) shows reproducible problems in this regard. I'm not a windows expert enough to tell but think @olamy has done already some analysis in the past about the Move/Sync problem. In general I think it would really be beneficial if resolver would simply use time-stamped SNAPSHOTs instead of "normalized", maybe one can even for a while simply **write** the SNAPSHOT as an additional file (on windows) and **symlink** under Linux but resolver use/returns the timestamped file to start a migration? > 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 > Assignee: Tamas Cservenak > 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)