Question about file locking in badger

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?

Thanks,
marty

Hey @mschoch,

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.

@ibrahim What do you reckon?

Hey @mschoch,
The code in windows_dir.go file hasn’t been touched in a while. I think there’s room for improvement. I’ve created an issue for using LockFileEx instead of CreateFile with no sharing mode. https://github.com/dgraph-io/badger/issues/1364

Thanks for the replies @mrjn and @ibrahim.

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.

marty

1 Like

@mschoch In both the repositories, the file locking code was written before golang added the LockFileEx API. The LockFileEx as added 9 months ago https://github.com/golang/sys/commit/bb3f8db39f24d596342144141f45701e604f5aed while both the projects have locking code which was written at least 2 years ago. That explains why they’re using syscall+unsafe.

Also, it looks like the first repository is no longer in use https://github.com/juju/fslock/issues/4

3 Likes