SQLite Browser fails to open a DB inside a wsl2 installation

[Because789]

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

[mgrojo]

"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?

[tomlagier]

I'm having this same issue with WSL1, no error message given. Are there logs somewhere I can take a look at?

[mgrojo]

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.

[karim]

@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.

[justinclift]

@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.

[karim]

That's a good idea, and not hard to do. I will label this as enhancement for now.

[mattwojo]

Following. :)

[jramiresbrito]

Following too :)

[ActiveChooN]

Following too

[GeoMaciolek]

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?

[blacksheepaul]

It seems still no solution