[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786923#comment-17786923
]
ASF GitHub Bot commented on MRESOLVER-372:
------------------------------------------
rdicroce commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815195848
So for shits and giggles, I decided to paste the 1.6.0 file copy code into
the 1.9.x branch. Here's what it looks like:
```
public static CollocatedTempFile newTempFile(Path file) throws
IOException {
Path parent = requireNonNull(file.getParent(), "file must have
parent");
Files.createDirectories(parent);
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
@Override
public Path getPath() {
return tempFile;
}
@Override
public void move() throws IOException {
try (InputStream in = Files.newInputStream(tempFile);
OutputStream out = Files.newOutputStream(file)) {
copy(out, in);
}
}
@Override
public void close() throws IOException {
Files.deleteIfExists(tempFile);
}
};
}
private static long copy( OutputStream os, InputStream is )
throws IOException
{
long total = 0L;
ByteBuffer buffer = ByteBuffer.allocate( 1024 * 32 );
byte[] array = buffer.array();
while ( true )
{
int bytes = is.read( array );
if ( bytes < 0 )
{
break;
}
os.write( array, 0, bytes );
total += bytes;
}
return total;
}
```
Then I tried the same test as before. This code did NOT throw an exception.
And it appears to have actually worked. The file on disk has different
timestamps inside the JAR. Eclipse even seems to have noticed that it changed,
although that's difficult to say for sure.
Why does this work and the other code doesn't? I have no idea. Probably has
something to do with the fact that this code actually copies the content of the
file, byte by byte. Whereas the MoveFile approach probably only tries to change
the actual location on disk that the file points to.
> 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)
