[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows

[ASF GitHub Bot (Jira)]

    [ 
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786713#comment-17786713
 ] 

ASF GitHub Bot commented on MRESOLVER-372:
------------------------------------------

laeubi commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814261616

   > I really hope "atomic on windows" will NOT replace the file and then throw 
😄 otherwise, am really unsure what that OS is able to guarantee for at all.
   
   You can just look into the Widnows File system implementation of the JDK to 
see whats going on.
   
   > If you check older resolvers (and let's assume "they worked"), they used 
pre-nio2 copy+delete
   
   "Old" code simply ignored when replace goes wrong, so you have the problem 
that afterwards you maybe use the old file. I don't say that new way is "wrong" 
just that not using atomic move does not solve the problem reported in the 
issue that is some other process (or the current) is currently opend that file 
and in such case you cam't overwrite/delete/replace/move ... to that file under 
windows.




> 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)