API is too restrictive for use on Windows.

[MMulthaupt]

The WinAPI LockFileEx function documentation states:

If the locking process opens the file a second time, it cannot access the specified region through this second handle until it unlocks the region.

However, flock.Flock does not expose its fh field. Furthermore, setFh() is hardcoded to create an os.O_RDONLY-flagged file handle, excluding write operations even if a user of flock used reflection to obtain the file handle.

[theckman]

Is it that the API is too restrictive for use on Windows, or that it doesn't support the full feature set that Windows offers through native APIs?

The second part is intentional. My goal when building the package was for building lockfiles separate from the data files it was operating on. So you use a common path to a lockfile, and then if you get that exclusive lock you can start working on the data files.

[MMulthaupt]

The second part is intentional. […] you use a common path to a lockfile, and then if you get that exclusive lock you can start working on the data files.

Oh. That was not clear to me. Is that reliable? The data files might have unsynced changes, no? I.e. any other processes writing the data files would have to cooperate. (Am no file system expert)

[theckman]

The other programs would need to try and take the same lockfile before interacting with the data files. This would be application logic that needs to be implemented.

[MMulthaupt]

Thank you for the clarification. I got it working very easily now. Closing.