Repair is downloading dblock files

One way to get this is to backup an empty file which makes only a metadata block in dlist, dindex, and dblock, yet recreate adds a row to the Block table with Hash 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= and Size 0 and VolumeID -1. It also downloads all the dblocks (in the test case of a new backup, only one) as the countMissingInformation query keeps thinking it’s not done. The query still returns that row after recreate. Backing up a 1 byte file made a data block, and a recreate didn’t show any dblock BackendEvent downloads. This explains some of my test-backup dblock downloads. I’m not sure whether it explains issues in “compact”.

https://github.com/duplicati/duplicati/blob/79d839546b238be79967bf8532267bfab2b08aa6/Duplicati/Library/Main/Database/LocalRecreateDatabase.cs#L551

I’ll say that I didn’t get in the Profiling log ALL the SQL I expected, but it did look like third pass log messages:

2018-12-04 15:19:06 -05 - [Verbose-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-ProcessingAllBlocklistVolumes]: Processing all of the 1 volumes for blocklists: duplicati-b028adca88d0446569e1a841f9f8dfd19.dblock.zip
2018-12-04 15:19:06 -05 - [Verbose-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-ProcessingAllBlocklistVolumes]: Processing all of the 1 volumes for blocklists

EDIT: To elaborate on the failure sequence that I began describing at link above, a countMissingInformation uses missingBlockInfo which gets upset by the VolumeID -1 that got written into the database by the backup. Some of my databases still have this -1. I haven’t found how to clear it. Some others have cleared somehow. Regardless, when countMissingInformation hits this sticky problem, it never passes the check if we are done which means it goes to the third pass and does ProcessingAllBlocklistVolumes which then downloads in vain.

I think one design question would be how an empty file is supposed to be represented. I’ve seen many ways, including one where I added an empty file late to a backup without this problem (hoping to induce it). Instead what happened was that the ID of the empty Blockset got no BlocksetID in BlocksetEntry, breaking the chain, whereas on the troubled database, the BlocksetID in BlocksetEntry has a BlockID leading to -1 in Block table, assuming I’m correctly understanding how these things link together. I wonder if there’s good documentation?