I was going to report a bug with the transition to lts-19.13 in stack.yaml as I couldn't get for instance commit d2bc2683173ca1ade437aa294b26fd5e54353a55 "lts-19.13 (ghc 9.0.2)" that introduced it to compile on windows (with stack). But then I procrastinated too long and commit d01530ac21aead6607085b5cc90b62a52acd03a9 came along which reverted the transition and went back to lts-18.13 due to Joey having trouble getting ghc 9.0.2 to install. That was kind of fortunate to me because I didn't want to be the bringer of bad news regarding Windows in a bug report setting.

The problem with compiling with LTS 19 on Windows is the following:

[109 of 670] Compiling Utility.LockFile.Windows

Utility\LockFile\Windows.hs:64:17: error:
    * Variable not in scope:
          :: LPTSTR
             -> AccessMode
             -> ShareMode
             -> GHC.Ptr.Ptr a0
             -> CreateMode
             -> FileAttributeOrFlag
             -> GHC.Ptr.Ptr a1
             -> IO HANDLE
    * Perhaps you meant `createFile' (imported from System.Win32.File)
64 |                 c_CreateFile c_f gENERIC_READ sharemode security_attributes

   |                 ^^^^^^^^^^^^
Completed 229 action(s).

--  While building package git-annex-10.20220624 (scroll up to its section to see the error) using:
      C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-220630-d2bc26831\.stack-work\dist\d53b6a14\setup\setup --builddir=.stack-work\dist\d53b6a14 build exe:git-annex --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1

I digged into this and it turned out that as of Win32- it does not include those bindings anymore that begin with c_ in its exports and considers them as internal details. Unfortunately in System.Win32.File the alternative, createFile, is a "cooked" API in the sense that if there are intermittent errors opening the file there is some Haskell code that busy-waits on behalf of the user. But according to Joey that is undesirable for a lockfile implementation (.\Utility\LockFile\Windows.hs:53):

 - Note that createFile busy-waits to try to avoid failing when some other
 - process briefly has a file open. But that would make checking locks
 - much more expensive, so is not done here. Thus, the use of c_CreateFile.

So what to do when the authors of package Win32 pull the rug from under you? Should we perhaps weave our own tiny c_CreateFile API with FFI, or, could we do without it and use one of the implementations using Windows LockFileEx, for instance the one by my compatriot: https://hackage.haskell.org/package/lukko

fixed --Joey