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.
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.