MSYS sqlite3 does not properly convert Windows paths

[LordAro]

Describe the issue

After a recent (long overdue) update to msys, sqlite is no longer convert absolute windows paths correctly, opting instead to try to append the absolute path to the current directory, creating something with some broken unicode in it. The MinGW sqlite package works as expected though, as do relative paths.

As I'm unsure whether it's sqlite itself or the msys runtime that's affecting this, I've included both package versions

works: sqlite3 3.30.0-1 msys2-runtime 3.1.5-3

does not work: sqlite3 3.35.5-1 msys2-runtime 3.2.0-8

Steps to Reproduce the Problem

1. In an MSYS terminal, run:

   sqlite3 `cygpath -am foo.db` .dbinfo

   (cygpath call unnecessary, just to ensure absolute mixed/windows path)

2. Get error something like Error: unable to open database "C:/msys64/home/LordAro/foo.db": unable to open database file
3. Run:

   sqlite3 foo.db .dbinfo

4. Get expected "unable to read database header" error (because the database doesn't exist)
5. In an MinGW64 terminal, run:

   sqlite3 `cygpath -am foo.db` .dbinfo

6. Get expected "unable to read database header" error (because the database doesn't exist)

Similar results with Windows paths as well.

Additional Context: Operating System, Screenshots

In Procmon I can see that the sqlite3 process is attempted to open a path "C:\msys64\home\LordAro\C\msys64\home\LordAro\foo.db" (note the unicode error)

• Windows 10 Pro version 21H1 64bit

[lazka]

In general, if Windows paths work it is just luck because cygwin forwards them as is... any operation on the paths in sqlite will result in breakage. Not sure if we can do anything about that..

[LordAro]

Perhaps? But it worked previously, and it still works for the MinGW sqlite, so clearly something doing some conversion somewhere.

I see from the git history that there was some major rework of the cygwin/msys patches for 3.33 - could be related?