New-MySQLiteDB

[bolte-io]

When creating a database file it doesn't release the file until you close the terminal, is this expected behaviour?

I was toying around and used the command and then tried to delete the database file, it cannot delete until the terminal that spawned it is closed.

[jdhitsolutions]

It might. MySql can be finicky. Do you have steps I can reproduce?

[bolte-io]

I use Windows Terminal with Powershell Core 7

1. Create a DB with New-MySQLiteDB "C:\Users\Admin\Desktop\Something.db" -Comment "Testing database".
2. Whilst the terminal is still open try and delete the newly created DB file (in windows explorer).

You should get an error about the file being locked/in use.

If I close the Terminal the file can then be deleted (doesn't matter if I use the Terminal directly or via VSCode)

[jdhitsolutions]

I can duplicate this behavior. I verified the database is being closed after it is created. I see the same behavior in Windows PowerShell. I'm not sure this is something I can fix. I am in the process of working on a new release with updated SQLIte binaries. Maybe there's something in a newer version that fixes this. Otherwise, I will need to document this.

[jdhitsolutions]

While you can't delete the file immediately in Explorer, if you wait a few minutes you should be able to. It looks like PowerShell maintains a lock until the next .NET garbage collection. This isn't a bug, it is how .NET works. If I create a database and then immediately invoke garbage collection, I can delete the file in Explorer.

new-mysqlitedb -Path c:\temp\something4.db -Comment "test database"
[system.gc]::Collect()

But I'd rather not artificially impose a garbage collection. It happens automatically every few minutes.

[bolte-io]

Ahh, at least there is an explanation. So this is why closing the terminal releases the file lock? Does that trigger a GC run?

[jdhitsolutions]

I don't know if technically closing the terminal triggers garbage collection but it does sever the lock.

[bolte-io]

Hmm. The only thing I was concerned about is other scripts etc not being able to do things with the file while the lock was present.

As that doesn't seem to be an issue we can call this one resolved.

[jdhitsolutions]

The assumption is that you are using the database from within your PowerShell session. If you are automating something else, you could always inject [system.gc]::Collect() into your code.

[jdhitsolutions]

I'll add a comment to the documentation.

[B-Art]

This is normal SQLite behaviour. In the documentation it says that it is not supposed to work with more than 1 proces action on the file. (There is no server involved, so the OS should be able to facilitate multiple processes contecting to 1 file) I know that Notepad++ does something different. It always save a copy of the original file (even if you did not save a file the content will be there when you restart Notepad++. You can even delete an original file and Notepad++ will detect it and ask what to do!)