edit methods crash on windows 10

[iamlgh]

input_output.t crashes on Windows for these methods: edit, edit_raw, edit_utf8, edit_lines, edit_lines_utf8, edit_lines_raw

When running "dmake test" the test output is:
t/input_output.t .................. 1/? # No tests run!

# Failed test 'No tests run for subtest "edit_utf8"'
# at t/input_output.t line 510.
Error rename on 'C:/Users/sdklsh/AppData/Local/Temp/wXkXjuMIYU17648706711264' -> 'C:/Users/sdklsh/AppData/Local/Temp/wXkXjuMIYU': Permission denied at t/input_output.t line 506.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 52.

If I put an eval around the call, the output from "dmake test" is this:
t/input_output.t .................. 1/?
# Failed test 'edit_utf8'
# at t/input_output.t line 509.
# got: 'Line1
# Line2
# ▒
# '
# expected: 'Row1
# Row2
# ▒
# '
# Looks like you failed 1 test of 1.

# Failed test 'edit_utf8'
# at t/input_output.t line 510.

I tried various versions from 0.77 (where the method was introduced) to 0.108. The result is always the same.

[iamlgh]

I am using Strawberry Perl 5.20.2

[dod38fr]

I'm running in a similar problem with the tests of Config::Model on Windows :

2021/11/04 23:25:07 write backend IniFile Config::Model::Backend::IniFile::write failed: Error rename on 'wr_root/backend_ini/ini1/etc/test.ini16362039398393' -> 'wr_root/backend_ini/ini1/etc/test.ini': Permission denied at C:\STRAWB~1\cpan\build\Config-Model-2.144-0\blib\lib/Config/Model/Backend/IniFile.pm line 202.
Error rename on 'wr_root/backend_ini/ini1/etc/test.ini16362039398393' -> 'wr_root/backend_ini/ini1/etc/test.ini': Permission denied at C:\STRAWB~1\cpan\build\Config-Model-2.144-0\blib\lib/Config/Model/Backend/IniFile.pm line 202.

This test code uses spew_utf8 to save test.ini file.

Perl is:

    osname=MSWin32
    osvers=5.1.2600
    archname=MSWin32-x86-multi-thread-64int
    uname='Win32 strawberry-perl 5.28.2.1 #1 Mon Apr 22 21:59:01 2019 i386'

[xdg]

From some research online, my best guess is that this is a race condition where the filehandle hasn't been released within the OS even after close is called, or, some other program like antivirus software has opened the file when the rename attempt happens.

I wonder if the answer is to put a retry around the rename.