POSIX fdatasync() is similar to fsync() but it tries not to sync non-needed metadata. If POSIX OS doesn't have it - it's safe to use fsync() (If we need to sync data to disk - we have to use one of these functions).

This change will help to run code with fdatasync() on MacOS without fallbacks in Python code.

I'll propose a PR soon.

fsync() may be slower than fdatasync(). There may be cases in which you prefer to not call fsync() or call it less often if POSIX fdatasync() is not available. To do this you should know whether Python fdatasync() calls POSIX fdatasync() or fsync(). The simplest way to provide this information to user is to not provide os.fdatasync() in the underlying system call is not available.

Note also that this change will not help to run code with fdatasync() on MacOS without fallbacks in Python code until you drop support of all Python versions older than 3.9.

If there is a way not to sync data - you should use neither fdatasync nor fsync.

So IMHO if someone wants to sync data and want to use fdatasync - I see the only way on MacOS is to use fsync().

> Note also that this change will not help to run code with fdatasync() on MacOS without fallbacks in Python code until you drop support of all Python versions older than 3.9.

I agree, but I propose to make this change in 3.9 to get it somewhere in future.

I want to add that it's a usual practice:
- https://github.com/libuv/libuv/pull/1580/files/bdd987a9b4347164e31e22d2d5ce06fbb5ebc859
- https://rev.ng/gitlab/revng/qemu/commit/6f1953c4c14566d3303709869fd26201828b3ccf

PR rebased and ready to review.

The os module provides a pretty low level simple shim over platform APIs. It is better for logic like this to live in a higher level application library rather than make big assumptions on the part of the user.

```
try:
    os.fdatasync(fd)
except Exception as err:
    logging.debug("fdatasync(fd) failed %s, falling back to fsync(fd)", err)
    os.fsync(fd)
```