SQLite Browser fails to open a DB inside a wsl2 installation
Because789 opened this issue · 34 comments
Details for the issue
What did you do?
I tried to open a SQLite database inside of a Windows Subsystem for Linux 2 installation (Ubuntu) and nothing happened. I copied the database to my desktop and the db opened fine.
That means, it did NOT work with this path:
\wsl$\Ubuntu\home\iamgroot\dev\dev.db
But it did work with this path:
C:\Users\iamgroot\Desktop\dev.db
I guess that behaviour is to be expected, since I try to open a file from a linux file system in a Windows software, and this issue therefore should be labeled feature request. But looking at the seemless integration of vscode and wsl2, it feels more like a bug...
Useful extra information
The info below often helps, please fill it out if you're able to. :)
What operating system are you using?
- [x ] Windows: ( version: 2004 (Build 19564.1005) with WSL 2 activated (Ubuntu))
What is your DB4S version?
- [ x] 3.11.2 (64bit for Windows)
Did you also
- Try out the latest nightly version: https://github.com/sqlitebrowser/sqlitebrowser#nightly-builds
- [x ] Search for an existing similar issue: https://github.com/sqlitebrowser/sqlitebrowser/issues?utf8=%E2%9C%93&q=is%3Aissue%20
"Virtual" filesystems usually give problems when opening an SQLite file inside them. See for example #2084. Isn't there any error message when you try to open the DB file?
I'm having this same issue with WSL1, no error message given. Are there logs somewhere I can take a look at?
Open it from a "Command Prompt" window; maybe it prints some error. When using a nightly build, there is also an error log in the "SQL Log" dock. You have to select it from the combo box.
Besides, have you checked whether you can write to the db file and the containing directory? Try opening it in read-only mode, and maybe the problem is skipped.
@Because789 Please check #2209 for more information.
I guess that behaviour is to be expected, since I try to open a file from a linux file system in a Windows software, and this issue therefore should be labeled feature request.
Unfortunately, there is nothing we can do here. WSL is not meant to run GUI apps. If you really want that, you can install an X Server on Windows.
But looking at the seemless integration of vscode and wsl2, it feels more like a bug...
VS Code is doing that using an extension (https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl). If you checked the first image in this link https://code.visualstudio.com/docs/remote/wsl you will see how it works.
Basically, you run VS Code on Windows and you just send/receive commands to WSL (Linux environment) in the background, for tools that are running on WSL.
I'm not sure how we can change Database Browser for SQLite to support WSL. If you want to open the app on Windows while the database is on Linux then I wouldn't recommended it with SQLite (the library).
SQLite does not work well on networked/virtualized/emulated file systems due to file locking issues that are unique to each file system. When more than one file system is involved, SQLite fails to operate correctly.
A different approach is to sync/copy the database file itself so you can have access to it on Windows and WSL, while opening it using the GUI on Windows only.
@karim At some future point, we could potentially do something similar to the DbAndroid plugin for SQLite Studio: https://github.com/pawelsalawa/sqlitestudio/wiki/DbAndroid
eg have a plugin that runs on the "remote" system (inside WSL in this case), and pipeline requests between DB4S and that plugin to "do stuff" in WSL.
Can't see it being something we'd do in the near future though, unless someone decides it'd be an interesting project to pick up sooner rather than later.
That's a good idea, and not hard to do. I will label this as enhancement for now.
Following. :)
Following too :)
Following too
Question - if the problem (or part of the problem?) is filesystem locking not being supported (on the \\wsl$\... share) - but, opening "readonly" - shouldn't we be able to skip file locking when opening readonly?
It seems still no solution
also following
Siguiendo,
Al intentar abrir un archivo database.sqlite de mi subsistema linux sqlite browser se queda en blanco
Gracias!
Continúa el problema, he intentado realizar la conexión con phpstorm y no permite hacerlo
It's still there (and following)
Could you please fix the SQLite Browser to show an error message when opening a database on a \\wsl$\ file system fails?
DB Browser for SQLite Version 3.12.2 still fails silently.
October 2022, Still fails silently on WSL2 Ubuntu. Windows 10
November 2022, same problem
Do other GUI applications works inside WSL? Aside from Visual Studio Code that is, which has it's own extension based workaround to support it (as mentioned above).
What I do as a workaround; I've set up & installed VcXsrv and run sqlitebrowser (and some other AppImages) from within WSL2.
Ahhhh, interesting. That's the "set up an X server" approach @karim mentioned. Does it work decently well?
WSLg works for this. That avoids the need to configure VcXsrv, and WSLg is now available for Windows 10 and Windows 11. (I've tried this from one of my Win11 systems -- I haven't confirmed that it works on my Win10 systems, but I've launched other Linux GUI apps there and expect it to work).
Awesome! That WSLg thing looks useful for people. 😄
@GusSand @noviceGuru @DerAlSem @Bilalharoon @guluguru @ActiveChooN @mattwojo @tomlagier This seems like it might be the right solution, at least for now. 😄
I'm using the version of sqlitebrowser that I install using apt.
@justinclift Actually this was my problem:
I used to think using SQLite browser in Windows, if I browsed to the correct directory to pick up my DB file (which is in my WSL), the browser would work, but I was wrong. The only way is to run it from WSL itself, and having Xserver , run the app graphically.
So you'll have to install Xserver on your Windows, get it running and test it, then use apt to install SQLite browser and then run it.
This link worked for me to get my Xserver running (which was a headache):
https://aalonso.dev/blog/how-to-use-gui-apps-in-wsl2-forwarding-x-server-cdj
With the latest WSLg, you don't have to install an Xserver yourself; it's built into WSL itself.
and expect it to work).
Wasn't aware of WSLg myself either, cheers for the heads up!
Edit: actually had to undo some of my manual Display setup for Xsrv, but it "just works™" now!
I installed and ran sqlitebrowser in WSLg on my Win10 systems and it worked fine there, too.
Awesome! 😄
WSLg works great. Thanks for the tips!
Since we have a good solution with WSLg, I'm gonna close this issue.
@Because789 using WSLg is a workaround. It is probably not suitable for everyone and the original bug is still there. I do not understand why this is considered to be a reason for closing the issue?
In my opinion the most serious part of the problem is not that it is not possible to open the file but that SQLite Browser does not show any error message explaining the problem and it leaves all the users to investigate what is going on.
but that SQLite Browser does not show any error message
Don't shoot the messenger.
If DB4S cannot see a file to open, it cannot open it. It cannot cast spells and summon the file to appear if the OS doesn't show it.
WSL is a 'feature' and it doesn't guarantee 100% that everything is going to work 100% with everything else.
I found this thread useful and just want to add some more details.
-
The error we got was a "Database is locked" message. So, at least there's an error message now!
-
In order to install SQLite Browser in WSL, follow the install instructions for Ubuntu on the Downloads page. Currently, these are the commands to run from a WSL Terminal:
sudo add-apt-repository -y ppa:linuxgndu/sqlitebrowser
sudo apt-get update
sudo apt-get install sqlitebrowser
- It then shows up as an app in the Start menu.