ATOMIC_MOVE fails under high frequency conditions on Windows

[Michael Osipov]

Am 2023-02-27 um 08:40 schrieb 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


Thanks Alan!

Please update the issue for "Affects Version" with 8 and 17 as well.

Regards,

Michael