Creating a bug report is a nice way to be able to investigate at leisure, but sometimes people won’t produce them (perhaps too difficult or too worrisome?). There might also be a 4 GB .zip size limit.
--zip-compression-zip64 (Boolean): Toggles Zip64 support
The zip64 format is required for files larger than 4GiB, use this flag to
toggle it
* default value: False
Alternatively, sometimes people will be able and willing to run queries, e.g. in DB Browser for SQLite.
To build on that idea, one can look at IndexBlockLink table. In my non-authoritative view, ideal is a match between Blocks (dblock files), Index (dindex files) and rows in IndexBlockLink table that pairs them, however adding a qualifier that Remotevolume shows State as Verified is safest, as sometimes others creep in. For example, I think Deleted is by-design there for awhile after a delete, which are often done.
Things that make you go, “Uh-oh.” kicked off a nice discussion, but someone would need to do a deeper code dive to figure out which which sort of mismatches (if any) cause immediate pains (e.g. in Recreate), and which can set the stage for later ones via some weird indirect mechanism. Because my code diving and SQL working are not the best, I run a DB recreation after hourly backup, and monitor its result code.
If it goes bad, I keep an enormous Profiling log and 30 versions of the database to help trace its history, however even a new proven “badness” check would be a nice enhancement to DB verifications arsenal, attempting to get early warning of cases that might want to read dblock files when recreating database.
Thanks for poking at this. There are also some pre-poked open issues that are in the bug fixing backlog.