Skip to content

[Windows] list_projects silently drops any .db file ≥ 2 GB — UI shows an empty project list #578

Description

@BombaxCeiba

[Windows] list_projects silently drops any .db file ≥ 2 GB — UI shows an empty project list

Summary

On Windows, the graph UI at http://localhost:9749 shows zero projects even
though valid <project>.db files exist in the cache directory. The list_projects
MCP tool — which the UI uses to populate the project list — returns:

{"projects":[],"hint":"No projects indexed. Call index_repository(repo_path=...) first."}

Root cause

In src/mcp/mcp.c, the project-DB scan uses the POSIX-flavored stat() from
<sys/stat.h>. On Windows (MinGW / MSVC default), struct stat::st_size is a
32-bit long, capped at 2 GB (LONG_MAX = 2,147,483,647). For any .db file
larger than 2 GB the call fails with errno = EOVERFLOW and the file is
silently skipped, so the projects JSON array ends up empty.

The same stat()-on-a-.db mistake appears in two more places in mcp.c
with their own symptoms — see Affected call sites.

Reproduction

  1. Windows 11, the codebase-memory-mcp-ui build (UI port 9749).
  2. Index a large repository so the resulting .db exceeds 2 GB
  3. Open http://localhost:9749 → empty list.
  4. Confirm via JSON-RPC:
    $body = '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_projects","arguments":{}}}'
    curl.exe -X POST "http://localhost:9749/rpc" -H "Content-Type: application/json" -d $body
    # → {"projects":[],"hint":"No projects indexed. ..."}
  5. Move the > 2 GB .db aside, or replace it with a < 2 GB project. The UI
    immediately lists the project — confirming stat() is the only filter that
    excludes it.

Why this is a real bug

  • No 2 GB size limit is stated anywhere in the project, so a .db larger than
    2 GB is expected to work — silently dropping it is a bug, not a documented
    constraint.
  • The failure is silent: no log line, no UI hint, no error in the JSON
    response. The indexer wrote files to disk, yet the UI claims "No projects
    indexed."
  • The fix is mechanical and the project already established the pattern
    elsewhere — it just wasn't applied uniformly.

Affected call sites

All three check a project .db with stat() and break on > 2 GB:

src/mcp/mcp.c   handle_list_projects       stat(full_path,&st) != 0   → project dropped from UI list
src/mcp/mcp.c   maybe_auto_index           stat(db_check,&st) == 0    → re-indexed on every server start
src/mcp/mcp.c   try_artifact_bootstrap     stat(db_buf,&db_st) != 0   → wasted artifact import (overwritten by rebuild)

(build_project_json_entry also read (int64_t)st->st_size, a 32-bit value
on Windows.)

Proposed fix

Replace all three stat() calls with the existing cbm_file_size helper
(foundation/platform.c), which is wide-char + 64-bit clean on Windows
(GetFileAttributesExW) and returns int64_t on both platforms. Full
details and the diff are in the linked PR.

Relation to prior Windows work (#386 / #394)

This is a distinct defect from the merged PR #386 (fix(windows): use wide-char API for non-ASCII path support), even though both touch the stat
surface:

  • fix(windows): use wide-char API for non-ASCII path support #386 fixed path encoding — non-ASCII UTF-8 paths (CJK / Cyrillic /
    Turkish) by swapping stat()_wstat64() + cbm_utf8_to_wide. Its file
    list (discover.c, compat_fs.c, platform.c, win_utf8.h) does not
    include mcp.c
    , so list_projects was never migrated.
  • This bug is the file-size dimension: struct stat::st_size is a 32-bit
    long on Windows, so a > 2 GB .db makes stat() fail with EOVERFLOW.
    That is orthogonal to path encoding — an all-ASCII path to a > 2 GB file
    still breaks.

Important: even if #386's wide_stat had been applied here it would not
fix this. wide_stat copies the _stat64 result back into struct stat,
whose st_size is still a 32-bit long on Windows, so the size would
truncate silently (the failure just changes shape). cbm_file_size returns
the size as int64_t, so it never passes through the 32-bit field.

Also not covered by #394 (Windows platform issues, 8 bugs) — none of its
sub-issues address the large-file / st_size-overflow class, so this is a new
entry in that cluster rather than a duplicate of existing work.

Environment

  • OS: Windows 11 Pro 10.0.26200
  • Build: codebase-memory-mcp-ui release asset (UI port 9749)
  • Cache dir: C:\Users\<user>\.cache\codebase-memory-mcp\
  • Offending DB size: > 2 GB

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions