mirror of
https://github.com/DeusData/codebase-memory-mcp.git
synced 2026-10-21 05:59:35 +08:00
Martin Vogel
f7e23d8483
The Unix-VFS MAX_PATHNAME bump from 512 to 4096 shipped with the daemon work but left no paper trail, so the next amalgamation refresh would silently revert it. Document it in vendored/sqlite3/PATCHES.md with the rationale and re-apply procedure, and point to it from THIRD_PARTY.md. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
19 lines
730 B
Markdown
19 lines
730 B
Markdown
# Local patches to the vendored SQLite amalgamation
|
|
|
|
Reapply every patch below after refreshing the amalgamation, then update
|
|
`scripts/vendored-checksums.txt` (`shasum -a 256 vendored/sqlite3/sqlite3.c`).
|
|
|
|
## 1. Unix VFS path ceiling: `MAX_PATHNAME` 512 → 4096
|
|
|
|
```c
|
|
#define MAX_PATHNAME 4096
|
|
```
|
|
|
|
Upstream's Unix VFS caps full database paths at 512 bytes, while CBM
|
|
supports 4 KiB paths everywhere else (cache roots under deep home
|
|
directories, long project paths on Linux). With the upstream value,
|
|
opening a store whose absolute path exceeds 512 bytes fails with
|
|
`SQLITE_CANTOPEN`. 4096 matches `PATH_MAX` on Linux and CBM's own path
|
|
buffers. Windows and the other VFS layers are unaffected (they do not
|
|
use `MAX_PATHNAME`).
|