Implement File#fsync on Windows

[kubo]

This PR uses _commit to implement File#fsync on Windows.

Metadata is also flushed as fsync.

• _commit calls FlushFileBuffers internally. (I checked it by looking the source code of crt installed with MSVC.)
• In CreateFileW document:

  To ensure that the metadata is flushed to disk, use the FlushFileBuffers function.

[kubo]

This issue was closed by mistake. I removed kubo:file-fsync-on-windows branch on my repository and it made this PR closed.

[bcardiff]

Why is it better to use _commit instead of the public API FlushFileBuffers ?

[kubo]

Why is it better to use _commit instead of the public API FlushFileBuffers ?

Does this sentence imply that _commit is not a public API?

[bcardiff]

I will rephrase. Why is _commit preferred instead of FlushFileBuffers? Since CreateFileW is used to create the handle and FlushFileBuffers is the suggested function to use, it seems strange to me to use _commit.

Does it do something else that is needed or they are aliases?

[kubo]

I use _commit because I think that crystal uses C-runtime low-level I/O mainly and uses Win32 API only when low-level I/O lacks ability. For example, File.open and File.delete use low-level I/O (_wopen and _wunlink), not Win32 API (CreateFileW and DeleteFileW). File.rename doesn't use low-level I/O because _rename lacks the ability to replace existing files. Well, this is just a guess. I may think too much.

I have no other reasons to use _commit. I feel no difference with the following code except error messages (based on errno or based on win32 error code) when the method fails.

  private def system_fsync(flush_metadata = true) : Nil
    if LibC.FlushFileBuffers(windows_handle) == 0
      raise IO::Error.from_winerror("Error syncing file")
    end
  end

Does it do something else that is needed or they are aliases?

_commit(fd) is same with FlushFileBuffers((HANDLE)_get_osfhandle(fd)) when error checking is omitted. As for the above crystal code, _get_osfhandle(fd) is called inside of windows_handle.

[bcardiff]

Ok, thanks for the explanation 🙇

[RX14]

It's intended that we migrate from the "half-posix" file API to the full windows API. I used the unix-like wrappers only because of the ease of storing a fd instead of a HANDLE*, but this all needs refactoring to ideally use handles everywhere.