I’ve been researching file locking options in Go and was reviewing the choices badger has made. In dir_windows.go the following comment appears, “this works but it’s a bit klunky. i’d prefer to use LockFileEx but it needs unsafe pkg”. (link removed because your forum software is bullshit)
I found this a bit surprising because badger does use the unsafe package in other places, and in particular the dir_unix.go relies on the “golang.org/x/sys/unix” package, which also uses unsafe.
Is the comment in dir_windows.go accurate, or is there some other reason to avoid using “golang.org/x/sys/windows” and LockFileEx?
Nice to hear from you. I’ve increased your trust level, so you should be able to post links now.
I think Windows has been a bit of a blind spot for us, considering most of our contributors are either on Mac or Linux. I don’t recall any specific reason we shouldn’t use sys/windows.
For the code I was working on I needed both exclusive and shared locks. I seem to be able to get the behavior I want with unix.Flock() and windows.LockFileEx() but I’ve found 2 other libraries which both seem to choose to invoke LockFileEx manually via syscall+unsafe instead of using the golang.org/x/sys/windows directly.
So while I think I have what I need working now, I’m left wondering if there is something more that I’m still missing. I’ve subscribed to the issue you created, so I’ll track which direction you go, and please share anything you learn along the way.
@mschoch In both the repositories, the file locking code was written before golang added the LockFileEx API. The LockFileEx as added 9 months ago windows: add LockFileEx, UnlockFileEx system calls · golang/sys@bb3f8db · GitHub while both the projects have locking code which was written at least 2 years ago. That explains why they’re using syscall+unsafe.