ADDITIONAL SYSTEM INFORMATION :
Stacktrace given here is for windows (WindowsFileCopy), but i have also heard it happens on linux (https://github.com/eclipse-equinox/equinox/issues/499)

A DESCRIPTION OF THE PROBLEM :
Files.move(source, target , StandardCopyOption.REPLACE_EXISTING) throws NoSuchFileException if the target file is deleted in parallel - after WindowsFileCopy detected it should delete the target but before it could delete it itself.

Caused by: java.nio.file.NoSuchFileException: (filename)
at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:85)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:403)
at java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:291)
at java.base/java.nio.file.Files.move(Files.java:1430)

if the target is gone and Files.move is supposed to delete it, then Files.move should ignore that the File is already deleted and continue with move.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
But a breakpoint in WindowsFileCopy.java:390

https://github.com/openjdk/jdk/blob/0377f1abe1c6f7b9b3d1599255166f9a7d68290a/src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java#L390

call Files.move(source, target , StandardCopyOption.REPLACE_EXISTING)

when breakpoint hit manually remove the target, resume the move => Exception

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No Exception
ACTUAL -
NoSuchFileException

CUSTOMER SUBMITTED WORKAROUND :
retry Files.move

FREQUENCY : always