Open WofWca opened 5 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!
Seems to be fixed in current release. Tested on Windows 10.
1.46.7 ? Nope, still buggy. Are you using the MS Store version?
Yes. Ok I will uninstall and reinstall to make sure the sandbox paths are used...
@nicodh Could you please clarify the current state of the issue, if you know off the top of your head? It doesn't affect fresh Microsoft Store installs, but affects all users who at some point had installed the Setup.exe version? Or just the ones who at some point had a pre- 1.46.7 installation?
I just tried a fresh install in a "fresh" Windows 10 install. The files are in sandbox and a the bug is not reproducable. If you had previously installed via Setup.exe even an install from store will save the data in AppData/Local...
Can you still reproduce it? Where is your data stored?
Mine is in \AppData\Local\DeltaChat
, and yes 1.46.8 (git: v1.33.0-989-g5018d9d4) from Microsoft Store still hangs and crashes.
Ok then we have to investigate further. The path only can't be the problem. I tested Store installs with both paths.
Here are fresh reproduction steps for 1.46.8:
AppData\Local\DeltaChat
AppData\Local\DeltaChat\logs
and not AppData\Local\Packages\merlinux.DeltaChat...\LocalCache\Local\DeltaChat
.💥 Delta Chat crashes.
The only way I managed to NOT reproduce the issue is by installing Delta Chat from Microsoft Store right away, prior to ever installing the Setup.exe version on a particular Windows installation.
AppData\Local\Packages\merlinux.DeltaChat...
database dir
is AppData\Local\DeltaChat\accounts\...
. In reality this directory does not exist!✅ Everything works fine!
And then if I additionally install the Setup.exe version and launch it, a new directory will be created, AppData\Local\DeltaChat
, and the accounts created in the Microsoft Store version will not appear there: the two instances of Delta Chat will act separately.
✅ No crashes will appear.
In short, I believe that Delta Chat is broken for all Windows users who have had a Setup.exe version prior to switching to the Microsoft Store version.
So I could reproduce this error with the install procedure as described above. The root cause is "failed to remove account data Caused by: The process cannot access the file because it is being used by another process. (os error 32)"
Since BackendRemote.rpc.removeAccount is called async the app waits quite some time for a response, which comes finally as an error and is catched in OnboardingScreen->onClickBackButton. There we only show an alert dialog if the error is of instance Error which is not the case (??). But there is a error.message, so maybe we should at least show that and redirect to the NoAccountSelected screen by calling window.__changeScreen(Screens.NoAccountSelected) after closing the dialog.
That would at least improve the user experience "a bit".
Finally it is only possible to solve the root cause in core. We have to find why there is "another process" using the account data. @link2xt
By the way - after reloading the website by pressing F5 in dev tools or by clicking the reload button on the crash screen everything works as expected and the temporary account is not visible any more (but the account data still exists on disk)
We have to find why there is "another process" using the account data
electron is likely the other process, like it it still holds a file handle to a file from the accounts blob directory like an image.
Also there are tools on windows that you can use to check what programs currently use a file. there is a tool for that in the power toys and you can browse open file handles with process explorer.
winget install --id Microsoft.PowerToys --source winget
Some more debugging.
I tried to use PowerToys. After clicking the "Delete Account" button, PowerToys shows no processes using the to-be-deleted account's folder. The same goes for the files inside., including dc.db
.
After the "Delete Account" is pressed, I can delete the account's directory myself using explorer and it doesn't complain that "it's being used by another process" (which is not the case if I try to delete the folder without pressing "Delete Account").
If I delete the directory manually this way while Delta Chat is hung, it doesn't unhang, but instead, after try_many_times
finishes, it gives a different error: "failed to remove account data\n\nCaused by:\n The system cannot find the file specified. (os error 2)"
: I assume it cannot find the account's directory (since I just deleted it).
If I instead delete the contents of the directory while Delta Chat is hung, it doesn't unhang either and, after a minute, the error remains to be the same (failed to remove account data\n\nCaused by:\n The process cannot access the file because it is being used by another process. (os error 32)
).
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.