That is a valid concern, but I believe it doesn't justify exposing entry names, as the effect would be the same if the file names were encrypted. Also rewriting only modified entries leaks which/how many are changed/unchanged/added/removed. My db looks entirely different on each write as it is encrypted as a whole with a random IV each time, and with compression you can't tell with certainty how many entries it has.
I'll look into fixing it the "rewrite to temp file then atomically rename" way, or perhaps rename the old one first and keep it around as a backup (which would also allow undoing mistakes).
I can't tell if you're suggesting SQLite as a solution to the same corruption problem or something unrelated, but either way, I'd prefer keeping it simple overall instead of depending on a more complex one-size-fits-all. Thanks for suggesting anyway.
> a simple custom vault format.
I understand what you're saying about password-store's directory structure exposing website names as plain text filenames...but, the upside of that design is that it tends to be very resilient.
imagine that you're updating an entry in your vault, and right as you save it you lose power, resulting in file corruption.
with password-store's design, the blast radius of the corruption is limited to that one single entry.
with your design, the potential blast radius of corruption could be my entire password vault.
in particular, looking at your file-management code [0, 1] it looks like it does a complete rewrite of the vault file on every save, without doing "rewrite to temp file then atomically rename" or any similar tricks meant to handle partial file writes.
if you haven't seen it before, I'd suggest reading "SQLite As An Application File Format" [2] and consider using SQLite as the storage backend.
0: https://codeberg.org/jlucas/pacc/src/branch/master/src/db.c
1: https://codeberg.org/jlucas/pacc/src/branch/master/src/vault...
2: https://sqlite.org/appfileformat.html