While it is not directly a bug of MariaDB, this is something that has affected us for a long time.
Occasionally, especially in situations where files are rapidly created, closed, reopened again,
a 3rd party software , usually an Antivirus, gets interested in them.

A well-behaving antivirus (or backup, or whatever) would open file such that it does not interfere with other operations (i.e FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE). Even a well behaving 3rd party software can sometimes be a problem, as in older Windows versions file does not go away after deletion, but only after the last open handle is closed, but we managed to work around it in most scenarios.

A not-so-well behaving 3rd party opens a file with different share flags, causing one of
CreateFile/DeleteFile/MoveFile functions to fail with Windows error code ERROR_SHARING_VIOLATION (32), which is often translated to POSIX's EACCES (13= permission denied).

While we recommend(or should recommend) excluding database directories from AV, we do not have control over it, and sometimes neither DBAs would not have this control. An example are the old buildbot boxes on Azure, where even a user with administrative rights can't turn off the AV scanning. Sometimes it is Windows Defender that misbehaves

The purpose of this task is to minimize number user-visible "permission denied" errors. The idea is to retry the failing API in a loop, if the function is failing with ERROR_SHARING_VIOLATION (in case of MoveFile, if destination file exists and is open, also ERROR_ACCESS_DENIED). We assume that the errors like this are transient, and a short loop is going to fix them, in most cases.

This work is going to be restricted to the mysys only, because currently we see errors there. Innodb has its own retry logic, so we won't touch it here.

At the moment MoveFile has already implemented the retry logic for my_rename(MDEV-28178)