Support opening files from WSL2 directories
Hi everyone, i just noticed that it is not possible to open files from an WSL (Windows Subsystem for Linux) environment when running the application from Windows 10.
So here is what i tried:
- Install XCA 2.4.0 for Windows 10
- Prepare a database in my WSL environment (Ubuntu 20.04)
- WSL 2 Kernel-Version: 5.10.60.1
- From Windows -> Open the database located at \wsl%\Ubuntu\my-path\my-database.xdb
It could be that this is not limited to WSL in general but network drives too but this is something i haven't tested yet.
Please let me know if you need more information on the subject.
What is the observed behavior when opening \wsl%\Ubuntu\my-path\my-database.xdb
(Error message, nothing, crash, hang)
Is it possible to import PEM items from the WSL?
I simply get an error prompt saying:
The following error occurred: Error opening file: '/Ubuntu/home/user/my-path/my-db.xdb': No error
So usually the file is password protected and i don't event get the password prompt. The file was initially created in the Windows environment and then moved into the WSL. When copying it back to the Windows environment everything is fine. As the file is shared among my team, it still can be opened from a Mac or Linux OS. So in general that works with the same file.
Edit: When importing a .pem file from WSL while the database is located in the Windows environment results in the following error prompt
The following error occurred: Error opening file: '/Ubuntu/home/user/my-cert.pem': Invalid argument
Hi @chris2511 do you need more information on the subject?
The format \wsl%\Ubuntu\my-path\my-database.xdb doesn't work at all on my Windows 10 with wsl; I use
\\wsl$\Ubuntu\home\{me}\{path}\{dbfilename}
File Explorer can't open \wsl% at all. The \\wsl$ is using the virtual network between windows and the wsl process to gain access. I'd retry using the \\wsl$\Ubuntu\... format and see if it works better.
We store our db on a windows share, which has new issues these days since the sql support doesn't seem to like running off a windows share anymore, but there was a different issue filed for that one.
Storing Sqlite files on a network share has several drawbacks: https://www.sqlite.org/faq.html#q5
People who have a lot of experience with Windows tell me that file locking of network files is
very buggy and is not dependable. If what they say is true, sharing an SQLite database between
two or more Windows machines might cause unexpected problems.
Sqlite not only requires access to the database file itself, but also to the containing directory to create short lived temporary files: https://www.sqlite.org/tempfiles.html
The rollback journal is always located in the same directory as the database file and has the same name
as the database file except with the 8 characters "-journal" appended.