ATOMIC_MOVE fails under high frequency conditions on Windows

[Alan Bateman]

On 26/02/2023 20:37, Michael Osipov wrote:
>
> The MoveFileEx does not properly block until the operation completes 
> and some Windows-internal locking fails the operation. Even the
> While investigating the problem, it seems to be very common on Windows 
> with Jenkins, Kafka, etc. but also Python folks discussed the issue 
> (https://github.com/python/cpython/issues/53074).
> Now, if I apply the following patch:
>> -                Files.move( tempFile, file, 
>> StandardCopyOption.ATOMIC_MOVE );
>> +                Kernel32.INSTANCE.MoveFileEx( 
>> tempFile.toAbsolutePath().toString(), file.toAbsolutePath().toString(),
>> +                    new DWORD( WinBase.MOVEFILE_REPLACE_EXISTING | 
>> WinBase.MOVEFILE_WRITE_THROUGH ) );
>
> It just works. MOVEFILE_WRITE_THROUGH guarantees the operaton to block 
> until it is completed.

Thanks for the bug report, I've created JDK-8303225 [1] to track this. 
On the surface, it seems that the JDK should use MOVEFILE_WRITE_THROUGH 
but it requires working through a bunch of scenarios to see what side 
effects might emerge (just about every change we do on Windows seems to 
have some side effect).

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8303225