Open WofWca opened 2 months ago
The process cannot access the file because it is being used by another process.
windows again (with its only one process can have a file handle at a time rule)... maybe we can just tell core to schedule it for deletion if it gets this error on windows, or somehow force that it become the sole process opening these files?
But now the interesting question would be what files are accessed, I guess blob files, but I'm not sure.
Any progress on this?
Not from me. It looks to me like it requires some core knowledge, which I don't have too much of.
We have try_many_times
workaround that we tried to remove at some point and then restored in https://github.com/deltachat/deltachat-core-rust/pull/4873 again because Windows CI failed due to the database not being closed. Now Delta Chat core tries to remove the folder 60 times for a minute, but apparently with microsoft store setup it is still not enough.
We should probably remove this try_many_times
and find actual reason the database stays open for some time after the context is dropped.
There was also an old issue discussing similar problem: https://github.com/deltachat/deltachat-core-rust/issues/2695
On desktop the error can be ignored, worst case the database remains on disk but it is a small unconfigured database. Core does not garbage-collect accounts folder, maybe we should do it as well to get rid of such databases that we failed to delete.
I also opened core issue: https://github.com/deltachat/deltachat-core-rust/issues/5809
I made a fix for the core: https://github.com/deltachat/deltachat-core-rust/pull/5814 Probably best thing to do now is to update the core to include this fix.
Basically this is how Windows works: Files stored in the Program Files
(sub)folder(s) are protected by user access control (UAC) in a way only an elevated user (who has applied for administrator rights before) is allowed to write into. The above log of the Microsoft Store version of Delta Chat does not seem to write to the current user profile (path C:\Users\[current user]
), but into the app folder instead, which is, what I believe, must not be permitted during runtime.
Edit: After looking into the log again, I have recognized that the database has been located in the user profile anyway, so mea culpa, and have a nice day!
This works fine on a manually downloaded 1.46.1, which is also built from 899f196d. Note that the manually installed one is 32 bit, and the Mircosoft Store is 64. Idk if this matters.
Here I clicked "Add Account" at 08:43:00, then clicked "back" at 08:44:09, then "back" again at 08:46:00, then "back" again at 08:49:00, then "Let's get started" at 08:49:19, after which the crash occurs:
The manually installed version's log (where everything works fine):
It appears like Core hangs on first "back" click, then on second click it tries to access the file but fails. But it's just my intuition. After the first "back" click it doesn't take much CPU time.
This is not a recent regression. I have been noticing this for a while, at least from 1.44, maybe earlier.