File locks now work on Windows (#480)

* File locks now work on Windows

Uses LockFileEx() and UnlockFileEx(). Fixes HDFFV-10191 (partial).

* Committing clang-format changes

* Committing clang-format changes

* Fixes commenting in h5repack

* Reworks H5Fis_accessible()

H5Fis_accessible() created a new file handle and attempted to read
through it, which will fail when a file has been opened with an
exclusive lock on operating systems that have mandatory locks.

This change uses the same scheme we use in H5Fopen() to check if
the file is already open and only tries to read the file signature
if the file has not already been opened.

Also adds a test for this behavior.

* Committing clang-format changes

* Trivial change to force github to run actions

Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

1 files changed, 17 insertions, 0 deletions

diff --git a/release_docs/RELEASE.txt b/release_docs/RELEASE.txt
index 242d3e6..13331b1 100644
--- a/release_docs/RELEASE.txt
+++ b/release_docs/RELEASE.txt
@@ -384,6 +384,23 @@ New Features
 
     Library:
     --------
+    - File locking now works on Windows
+
+      Since version 1.10.0, the HDF5 library has used a file locking scheme
+      to help enforce one reader at a time accessing an HDF5 file, which can
+      be helpful when setting up readers and writers to use the single-
+      writer/multiple-readers (SWMR) access pattern.
+
+      In the past, this was only functional on POSIX systems where flock() or
+      fcntl() were present. Windows used a no-op stub that always succeeded.
+
+      HDF5 now uses LockFileEx() and UnlockFileEx() to lock the file using the
+      same scheme as POSIX systems. We lock the entire file when we set up the
+      locks (by passing DWORDMAX as both size parameters to LockFileEx()).
+
+        (DER - 2021/03/19, HDFFV-10191)
+
+
     - H5Epush_ret() now requires a trailing semicolon
 
         H5Epush_ret() is a function-like macro that has been changed to