FULL PRODUCT VERSION :
Observed with

java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)

as well as the 32-bit variant.

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]


A DESCRIPTION OF THE PROBLEM :
JDK-8021384 was closed as "incomplete" with speculation that it may be a Samba/network issue. However, I have occasionally-but-regularly seen the exact same behavior, including the stack trace, using nothing but local regular drives.

I've seen it with standard edition 7 and 8, but haven't tried any of the specialized editions.

I say "occasionally-but-regularly" because the problem is intermittent, exactly as in the 8021384 report. Simply doing the same steps over and over will eventually trigger the bug, but I've found no indicators of what else might be causing it.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Same as in 8021384:
- write arbitrary data to a file "source"
- close :source"
- use "Files.move (source, dest, StandardCopyOption.REPLACE_EXISTING)"

In my particular case, my program has already verified that "dest" can be deleted (which is what Files.move will do).



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Given the presence of REPLACE_EXISTING, I expect the call to succeed.

ACTUAL -
Almost every time, the operation is fine. At seemingly random occasions, java.nio.file.FileAlreadyExistsException is thrown, which Files.move() documents as only being thrown in the specific case when REPLACE_EXISTING is *not* present.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.nio.file.FileAlreadyExistsException: C:\Users\test\Desktop\hold.delkeywk857.tmp -> C:\Users\test\Desktop\targ.s
        at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:81) ~[na:1.8.0_71]
        at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) ~[na:1.8.0_71]
        at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387) ~[na:1.8.0_71]
        at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287) ~[na:1.8.0_71]
        at java.nio.file.Files.move(Files.java:1395) ~[na:1.8.0_71]


REPRODUCIBILITY :
This bug can be reproduced occasionally.

---------- BEGIN SOURCE ----------
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.nio.file.StandardCopyOption;

public class Bug
{
        public static void main (String[] args)
        {
                try {
                        Path src = Paths.get(args[0]);
                        Path dest = Paths.get(args[1]);

                        Files.move (src, dest, StandardCopyOption.REPLACE_EXISTING);
                }
                catch (Throwable e) {
                        e.printStackTrace();
                }
        }
}

Just running this enough times with random files, on the same filesystem, will cause the bug. There's no need to especially stress the filesystem, just a normal "human" pace of file operations will do it.

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Waiting several seconds and trying again often works. It seems to simply be DeleteFile (windows/classes/sun/nio/fs/WindowsFileCopy,java:363) succeeding, but then MoveFileEx on line 383 failing.

At an offhand guess, I wonder why the flags to MoveFileEx are zero instead of testing for the local 'replaceExisting' and passing MOVEFILE_REPLACE_EXISTING if it's true. The target file is *supposed* to be gone by that point, but... I've not been able to test this approach because I haven't been able to build a debugging JDK from scratch; also there may easily be aspects of Windows that preclude this approach; I am not familiar with the guts of Windows filesystems.