fix: open SQLite on Windows long paths normalised to forward slashes - #133
Merged
Conversation
get_sqlite_db_path detected the \\?\ extended-length prefix by its backslashes only. An artifact that normalises a path to forward slashes, a common idiom for its own path matching, turns that prefix into //?/. That form matched none of the checks, fell through to the normal-path branch, and had a second \\?\ prepended, producing \\?\//?/D:/... which SQLite cannot open. The database then failed to open on any Windows output path over 260 characters, and every SQLite artifact reading such a path silently lost its data. Restore backslashes before inspecting the prefix. '/' is never a valid filename character on Windows and \\?\ paths require backslashes, so the conversion is always safe there. All four incoming forms (backslash or forward slash, extended or plain) now collapse to the single valid \\?\D:\...\file.db URI the helper already produced for backslash inputs, so paths that work today are byte-for-byte unchanged. Reported by Mattia Epifani, who hit it on a long ALEAPP output path. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds a Windows-only regression test for the get_sqlite_db_path fix in the previous commit. It builds a real SQLite database at a path over 260 characters through the \\?\ extended prefix, normalises that path to forward slashes the way an artifact does, and asserts open_sqlite_db_readonly returns a usable connection and reads a row back. A negative control reproduces the pre-fix URI (\\?\//?/...) and asserts it really fails to open on the runner, so the positive assertion is not vacuous. The ubuntu runtime-contract job discovers the file and skips it, since \\?\ extended-length paths are a Windows-only concept. windows_smoke.yml runs it for real, alongside the existing import smoke test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
get_sqlite_db_path()inscripts/ilapfuncs.pybuilds thefile:URI thatopen_sqlite_db_readonly()andattach_sqlite_db_readonly()use. It detected the Windowsextended-length prefix
\\?\by its backslashes only.Many artifacts normalise a path to forward slashes for their own matching (splitting on
/,checking
/mirror/) and then open that same string. On a Windows output path over 260characters, the seeker path already carries the
\\?\long-path prefix, so normalising turnsit into
//?/. That matched none of the prefix checks, fell to the normal-path branch, andgot a second
\\?\prepended:file:%5C%5C%3F%5C//%3F/D:/...?mode=rodecodes to\\?\//?/D:/...SQLite returns "unable to open database file", the helper returns
None, and the artifactloses its data.
siminfoandusageappsare two confirmed cases. The forward-slash idiom iscommon, so a per-artifact fix would be whack-a-mole; the helper is the right place.
The fix
One line: restore backslashes before inspecting the prefix.
/is never a valid filename character on Windows and\\?\paths require backslashes, sothis is always safe there. All four incoming forms (backslash or forward slash, extended or
plain) collapse to the single valid
\\?\D:\...\file.dbURI the helper already produced forbackslash inputs.
Testing
//?/D:/...andD:/...to a valid\\?\D:\...URI, and leaves backslash-extended, plain-backslash, spaces /#, andextended-UNC inputs byte-for-byte identical to before. No regression to working paths.
2, SMS 123, MMS 12, Contacts 12), zero errors. Expected, since the change is inside the
Windows-only branch.
the platform this fixes and it needs a Windows run to close out. The change introduces no
new URI form: it routes the broken inputs onto the backslash-extended URI that already
ships and works.
Leveled across all five cores (iLEAPP, ALEAPP, RLEAPP, VLEAPP, DLEAPP); the helper is
identical in each.
Reported by Mattia Epifani.