-
Notifications
You must be signed in to change notification settings - Fork 29.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support fs.flockSync and fs.funlockSync #49256
Comments
This is the wrong repo for that, a cross-platform flock() would need to be added to libuv first. |
And the fact Deno is broken here on the most popular operating system isn't really super confidence inspiring. Here is the repo btw https://github.com/libuv/libuv |
As for the actual use case and not feature request you have several options:
But I think asking for file locking in libuv is reasonable, |
It's been asked before in libuv and the answer is no because cross-platform file locking is broken beyond repair or redemption (as deno found out): libuv/libuv#657 (comment) I'll go ahead and close this because this is one of those things that's simply not happening, sorry. |
That's an implementation detail of Node, this is the right repo for proposing a change to Node's public API. On the contrary libuv is obviously the wrong repo for proposing adding
Well, if using native bindings for a user are a pain for that user they just are a pain for them, you can't just decree that they are not painful in general. Maybe more interestingly: try to think of all the effort necessary to build native bindings to a version of sqlite compiled with custom flags that works across platforms in Electron... That's obviously way more complicated than compiling sqlite to wasm and just using it.
You are totally missing the point here, sqlite needs to be able to lock a file in order to not corrupt the database when accessing it via two different instances of sqlite. That module can't be working correctly precisely for the issue I'm mentioning, it can't lock files, because Node doesn't provide APIs for that, so it can't prevent corruption, so it's not a viable alternative, obviously.
That's not how this works at all though. You need cooperation between different sqlite instances, you can't just make up whatever file locking convention you please, sqlite by default uses advisory locking, if a database is opened by an instance of sqlite that uses some custom locking logic, and by a normal version of sqlite that instead uses advisory locking they would just not be able to see each other's locks, so you'll get corruption just the same.
Node has had, and probably still has, APIs that don't work across all supported OS', so I don't see why providing an API that only works on macos/linux would be deal breaker here. Besides if providing locking for Windows is really hopeless, then libraries that ship native bindings to sqlite like Can we re-open this, since there's still value to providing linux/macos-only locking APIs, even if libuv doesn't want to add provide them? |
Why not just write your own bindings for |
It's an option I'm considering, but it would go against one of my objectives, which is not relying on any native modules, which are a pain to work with in general, for me and my use case. |
https://github.com/yodaos-project/node-flock looks pretty ok if not entirely up to date? |
Maybe it's an OK native module, I can't say if the implementation is correct nor if anybody is actually relying on it (pretty flat ~2 downloads/week on npm). Like all native modules it is a pain in the ass to use for me and for my use case though, so I'd rather not go that direction. |
Very few, almost none. The guiding principle since well before 1.0 has been that if it can't be implemented faithfully on all supported platforms, it isn't implemented at all, with very few exceptions. For libuv the bar is even higher. I'm not going to rehash all the problems with file locking, just suffice to say that it's broken in different ways on different platforms. If you want file locking, cool, but you'll have to get it through a native module. |
What is the problem this feature will solve?
These APIs are needed for important functionality, like implementing a virtual file-system layer for sqlite: example.
Without them something like
x/sqlite
can't quite be cleanly ported from Deno.What is the feature you are proposing to solve the problem?
I propose adding:
fs.flockSync
: equivalent toDeno.flockSync
.fs.funlockSync
: equivalent toDeno.funlockSync
.We should probably close the gap with Deno here.
What alternatives have you considered?
I haven't found a nice one yet, I guess I could:
Maybe the only somewhat reasonable alternative would be to manually implement some form of locking in userland, which would still make it unsafe to open the same database with other sqlite builds though, which is not ideal.
The text was updated successfully, but these errors were encountered: