Closed gaodeng closed 5 years ago
I ran into the same issue. There should be no reason why we would not be allowed to change a file we created ourselves, so my guess is that Windows Defender is preventing this because we interact with the file too often. I've added the entire program folder of my vue-electron app as an exception, so I guess I'll see what that brings in a short while.
Unfortunately this error completely stops the program from working, so we should add least add some error handling and back up methods for this.
Adding the exception did not help, unfortunately. Issue seems to have been reported in electron-store
though: https://github.com/sindresorhus/electron-store/issues/31
I also encountered the same problem, is there a way to solve it?
I've just spent a few hours hunting this down. The following is my understanding...
Ultimately, I think the issue comes from here.
vuex-electron
uses electron-store
which uses conf
which uses write-file-atomic
. The latter has a function, writeFileSync
, which is supposed to prevent multiple processes from overwriting the vuex.json
file at the same time. It does this by taking a copy of it, editing the copy, then renaming that copy to replace the original. The rename command is this:
fs.renameSync(tmpfile, filename)
It turns out that in Windows (and it seems Windows only), the rename ability is not atomic; i.e. multiple processes can try to do it at once. When one process has beaten another to it, you get this EPERM error.
The solution for my application is going to be to throttle the use of setState()
in vuex-electron. This is built on top of my previous fork which only allows the main function to write to the store (whereas this library currently lets the renderers to the writing also). I'll share a link to my version some time soon.
I may do a pull request in time but I think we need to offer developers the option of using a throttle or debounce and let them choose what is appropriate for them.
I'm new in node
, electron
, vue
.
But some questions:
Is there a workaround for this bug?
I understand that the problem is in electron-store
. If so, why is the yarn.lock
file set to me like this:
electron-store@^2.0.0:
version "2.0.0"
resolved "https://registry.yarnpkg.com/electron-store/-/electron-store-2.0.0.tgz#1035cca2a95409d1f54c7466606345852450d64a"
integrity sha512-1WCFYHsYvZBqDsoaS0Relnz0rd81ZkBAI0Fgx7Nq2UWU77rSNs1qxm4S6uH7TCZ0bV3LQpJFk7id/is/ZgoOPA==
dependencies:
conf "^2.0.0"
And if I add the electron-store
to the package.json
file, does the yarn.lock
file add a new record ?:
electron-store@^2.0.0:
version "2.0.0"
resolved "https://registry.yarnpkg.com/electron-store/-/electron-store-2.0.0.tgz#1035cca2a95409d1f54c7466606345852450d64a"
integrity sha512-1WCFYHsYvZBqDsoaS0Relnz0rd81ZkBAI0Fgx7Nq2UWU77rSNs1qxm4S6uH7TCZ0bV3LQpJFk7id/is/ZgoOPA==
dependencies:
conf "^2.0.0"
electron-store@^5.1.0:
version "5.1.0"
resolved "https://registry.yarnpkg.com/electron-store/-/electron-store-5.1.0.tgz#0b3cb66b15d0002678fc5c13e8b0c38a8678d670"
integrity sha512-uhAF/4+zDb+y0hWqlBirEPEAR4ciCZDp4fRWGFNV62bG+ArdQPpXk7jS0MEVj3CfcG5V7hx7Dpq5oD+1j6GD8Q==
dependencies:
conf "^6.2.0"
type-fest "^0.7.1"
Why does electron-store
stay in version 2?
Is this repository managed? I understand that this is just a plugin for vuex
. Could it be time for fork or new development?
Is this repository managed? I understand that this is just a plugin for vuex. Could it be time for fork or new development?
Is there a workaround for this bug?
I have created a fix (by throttling setState). I'll put it on my fork later today and share a link.
@baruchiro Regarding your yarn thing ...
My understanding is that electron-store@2.0.0 is kept because it is a dependency of this project. The problem, however, is with write-file-atomic
and Windows.
My workaround was done one commit to adding all items in a collection, instead of committing each.
@baruchiro Feel free to try my forked repo.
When you initiate createPersistedState()
, you can include throttle
(number in milliseconds) in your options; e.g.
createPersistedState({throttle: 1000})
This will mean the app writes to disk a maximum of once every second. It's worked well for me. It's also a trailing throttle, meaning the last setState will be applied so long as the app isn't closed with throttle
milliseconds.
@michaeljpeake Does your fork have a package?
You should be able to install it with npm install git+https://github.com/michaeljpeake/vuex-electron.git
@michaeljpeake there was an issue with your last
variable. i forked the fork and it's working great. the slight delay in state change is a good compromise to avoid those annoying errors.
Thanks @tominal. I see I changed the variable name but not its declaration. Oops. Fixed in my repo too now, in case I come back to it.
Compromise is a suitable word. It doesn't feel quite right but it seems to be working. Also, if your store gets big, it's probably desirable to avoid writing it to disk constantly.
@michaeljpeake
You should be able to install it with
npm install git+https://github.com/michaeljpeake/vuex-electron.git
somewhere of the filenode_modules/vuex-electron/dist/persisted-state.js
, need to modify to :
var last, e = Date.now();
Thanks @suifengtec. I needed to actually build the thing rather than just update the src code.
You should be able to install it with
npm install git+https://github.com/michaeljpeake/vuex-electron.git
Hi @michaeljpeake
Any specific reason you decided not to publish a new npm module?. Please do consider publishing a package on npm with your forked repo.
Thank you.