mattn/go-sqlite3

v1.14.15 breaks existing working code using proc fs-based paths

thediveo opened this issue · 6 comments

thediveo commented

After upgrading to v1.14.15 my unit tests of a company-internal project started to fail. More investigation showed that v1.14.14 works as before, but v1.14.15 fails when trying to open and ping an sqlite3 database using a path that starts with /proc/12345/root/... (where 12345 is some PID). Up to v1.14.14 this was never a problem, but suddenly it breaks existing code.

  • Linux Ubuntu 22.04.1LTS
  • Go 1.19

Any idea why is this so?

rittneje commented

What is the specific failure you are seeing?

thediveo commented

Sorry, forgot to include the exact error:

<sqlite3.Error>: {
          Code: 14,
          ExtendedCode: 14,
          SystemErrno: 0x2,
          err: "unable to open database file",
 }

It gets thrown when calling Ping on the connection returned by Open.

thediveo commented

Database gets opened with ?mode=ro, but that doesn't seem to make a difference.

rittneje commented

I am not able to reproduce this issue on my local machine. My guess is it is related to this item from the 3.39.0 release of SQLite itself.

The unix os interface resolves all symbolic links in database filenames to create a canonical name for the database before the file is opened.

  • 👍1
thediveo commented

Now that sounds like a reason to break things, as it will trip over the way parts of procfs work.

thediveo commented

It is a breaking chance in sqlite3. IMHO overachieving because instead of only making sure to get the correct database name, they're now checking everything even if that does not solve the original problem and instead break things.

I'm closing this issue as it is upstream. Thank you for looking into this.

Hopefully, the pure go sqlite3 implementations don't make the same mistake...