The file data_level0.bin contains only empty bytes

[almirus]

Sorry for tagging you @mvalentsev. The file (data_level0.bin) size is increasing, but it contains only zeros—I’m not sure if that’s normal or not. At the same time, SQLite seems to contain some keywords. I’m using MCP in Cursor.

mempalace status

=======================================================
  MemPalace Status — 3 drawers
=======================================================

  WING: Orua D3
    ROOM: auro3d-decode            1 drawers
    ROOM: decoder-re               1 drawers

  WING: wing_codex
    ROOM: diary                    1 drawers

=======================================================

[mvalentsev]

I don't use Cursor so can't reproduce now. This would be better tracked as an issue. I'll set up Cursor later today and try to reproduce with a fresh palace. Will report back.

[almirus]

Do I understand correctly that this is the main “table” with weights/vectors?

[mvalentsev]

hnswlib index. Maybe #538 or #823. Try mempalace mine <dir> preferably with the latest develop branch.

[mvalentsev]

Hi! Did it work?

[almirus]

I removed the release version, completely deleted the storage (the entire directory), and installed the DEV version. In Cursor, I asked it to initialize and save facts—those seem to have been saved, but now both data_level0.bin files contain only zeros...

$ mempalace status

=======================================================
  MemPalace Status — 1 drawers
=======================================================

  WING: orua_d3
    ROOM: general                  1 drawers

=======================================================

.mempalace.zip

[mvalentsev]

Looked at your zip -- you have 1 drawer saved (wing orua_d3, room general, from .qwen/settings.json) plus 5 KG triples in knowledge_graph.sqlite3.

Try mempalace search findstr or mempalace search "Bash permissions" -- should return the drawer. If it does, the in-memory index is fine and the zeros in data_level0.bin are just hnswlib's pre-allocated buffer.

This is expected ChromaDB behavior (#823): hnswlib reserves space for the default 1000 max_elements upfront and writes real vectors to disk only on flush (at hnsw:sync_threshold, default 1000 new vectors, or on graceful close). With 1 drawer queued, no flush yet. The file fills naturally once you accumulate more or after a clean shutdown.

The KG triples you added land in a separate SQLite (knowledge_graph.sqlite3), which is why that side looks populated independently.

Just ask the assistant in chat: "search my palace for findstr".