cannot open about walletwasabi HOT 7 CLOSED

you implemented the database, right?

Yes.

Microsoft doesn't really support parallel database queries, which is why we often lock database retrievals to ensure there are no collisions.

Yes.

As I saw in the code, we connect to the database only once and from then on, we just send commands to it.

Yes. That was an intentional design choice at the time of implementation. More can be read here.

My suggestion would be to connect to the database with every command we send, and then disconnect from it once we're done, because we can't know when and on what thread we might want to access the file, especially if some error occurs. In that case, the program is likely to keep the file open when it shouldn't.

I don't follow this train of thought. I would recommend to read #10272 (comment) so that we are on the same page with regards to what we want from that SQLite database.

But I would like to point out that your approach has a potential downside as well - notably: Suppose that WW works as you suggest and then suppose that at some point you don't need the database, so there is no active connection to it. And suppose that some external process opens that sqlite database with an exclusive lock¹, then very likely you can crash WW because it will be unable to work with the database. That was one of the reasons why I implemented single connection that has the same lifetime as the application itself, because once you start the application and it initializes, you know it will keep working. At least, that's the idea behind it.

In that case, the program is likely to keep the file open when it shouldn't.

I don't follow this. If the program refers to WW, then WW is supposed to be able to be run just once (because we don't allow to run two instances at the same time). Then the one (and only) instance connects to the SQLite database and releases the connection when it crashes (because when a program crashes, OS cleans up file descriptors and releases resources, so next time you should be able to start WW just fine).

Can we do a test on this?

I would prefer to understand first why you think it should fix this issue. I don't think it will fix this issue. However, if you are right, i guess you can repro this issue easily by crashing WW and then trying to start WW again.

This is my take. Feel free to point out if I'm wrong on any point.

edit: If I were to guess, what this is about, I would guess that an antivirus program scans files and Wasabi attempts to start to find out that the file is locked and crashes. This would explain also #11873. But that would be only a good explanation if you one would observe:

1. Start WW
2. Crash
3. Start WW again
4. No crash.

but I'm not sure if that's what people observe.

Another explanation might be that our check for starting WW multiple times does not work correctly in all cases² and user succeeds in starting WW twice, then the second instance should crash, or maybe both instances based on conditions.

Another explanation might be that we initialize stuff incorrectly but I don't observe this on my machine.

from walletwasabi.

Maybe there is a process that has locked your database.

One approach is to find the process that has locked your file (see an answer) to get to the bottom of this.

The other approach is just to restart your machine and thus making sure that no such process can exist.

from walletwasabi.

@kiminuo you implemented the database, right? Microsoft doesn't really support parallel database queries, which is why we often lock database retrievals to ensure there are no collisions. As I saw in the code, we connect to the database only once and from then on, we just send commands to it. My suggestion would be to connect to the database with every command we send, and then disconnect from it once we're done, because we can't know when and on what thread we might want to access the file, especially if some error occurs. In that case, the program is likely to keep the file open when it shouldn't. I think the best and most sensible solution is not to have a constant connection to the SQLite database, but only when we want to start doing something with it. Can we do a test on this?

from walletwasabi.

Okay, you're right. Thank you for the explanation, and I have read the topics where similar thoughts were discussed, so I also consider this part closed on my end. But if opening the file sometimes causes problems in several areas, maybe at the start of the program, we should do a preliminary check to see if all the files we're going to lock are accessible?

You are also right that this is currently not a high-priority task, but if I receive a message from the user side that I need to restart my computer, that's a bad policy, I think.

from walletwasabi.

But if opening the file sometimes causes problems in several areas, maybe at the start of the program, we should do a preliminary check to see if all the files we're going to lock are accessible?

I tend to think that it's not correct because it feels like the solution would be similar to:

if (File.Exists(path)) { // (1)
  var f = File.Open(path, ..); // Here it's not guaranteed that the file exists because it might have been deleted after line (1)
}

That is to say, you can do the check, something locks your file, and the issue is there again. So the approach "narrows down the window where the issue might happen" but it does not feel like a robust solution to me. But then improving the message we report to user might be good.

You are also right that this is currently not a high-priority task

I didn't say that.

I think we need clear instructions how to reproduce the issue then we can fix it. Otherwise, we are just chasing ghosts. I was thinking about it and maybe we can set up a virtual machine with Windows, install WW there and run it to see if Defender locks files. But it's a long shot.

from walletwasabi.

Should be fixed with #12878.

Edit: Very likely a duplicate of #11638.

from walletwasabi.

from walletwasabi.