There are a few milder-than-that ones in the Issues of repair with a stale database from an image restore or with a two machine use case. Neither is legal, but prevention and detection could be improved. Until a better way is devised, I suggested looking at dlist files. Anything impossibly new per DB is a red flag…
I don’t know if it would have to be lots, but someone needs to read C# and SQL (or test…) to decide that.
Uploading is after making of files, so shouldn’t influence packing of dblock. I don’t think I follow this idea.
Right, they’re what allow database recreation without reading dblock files to figure out where things live.
index-file-policy is a configuration control, but by default the dindex has not only a list of block hashes in associated dblock, but also contains, in list folder, redundant blocklist information to avoid dblock read.
The dlist file doesn’t enumerate all the blocks for a file. For multi-block file, it indirects through a blocklist, some of whose blocks might be in a different dblock file (deduplication). Recreate has to find the blocks.
Processing a large file in blocklists: gives an example of a blocklist hash, used to locate the blocklist, which lives in a blockset. Source file data and metadata are also blockset uses, and blocks are in dblock.
Database rebuild was an attempt to try to sort this out. Channel Pipeline was too, but with different focus.