Duplicati User’s Manual in the Articles section says how Backup and Restore work. Unfortunately there’s no equivalent article that talks about Repair (possibly because its behavior is variable depending on the need). The REPAIR command doesn’t say much, and Tries is a key word. Sometimes it can repair, sometimes not. Currently a good way to forecast whether it will work is to read other reports (nice list BTW) and their efforts.
My take on the complaint is that this is a Duplicati check on itself finding inconsistency between a table that can quickly give file length, and a different table used for file reassembly from blocks, BUT none are noted. Although I can’t say that cause is the same (cause is unknown, at least to me), this reminds me of a similar error where there ARE blocks noted as in that file, but their lengths added up don’t total to other file length.
Here is the code and the very simple SQL behind your error. Not far above it is the code of the similar issue which produces “Found inconsistency in the following files while validating database” using a little more SQL
I was hoping your steps would reproduce the error, but they never managed to recreate the database issue. Mine used two Command Prompt windows of an Administrator user, with just one using Run as administrator. Duplicati.GUI.TrayIcon.exe manually launched from one or the other. I didn’t reboot but I did restart Duplicati. The backed up areas also weren’t big, and changes were rare. Are you willing to test again, maybe simpler?
Maybe a more direct path (if you still have a failing database) is to open it in DB Browser for SQLite and run:
SELECT * FROM “Blockset” WHERE “Length” > 0 AND “ID” NOT IN (SELECT “BlocksetId” FROM “BlocksetEntry”);
to see what files it’s complaining about. While I know there are privacy issues, sometimes names are needed, not so much by others, but by you to see where the problem files came from. Having done that, you could get a sanitized-for-names-and-other-things database bug report, post it somewhere, and give a link in the forum. This would also reverse the weak encryption put on the database in Windows. If you want a direct view, you’d start the Server or TrayIcon with --unencrypted-database before opening DB in your favorite SQLite browser.
To decode the SQL some, a Blockset table row has a file, which has a length, and an ID which also locates its blocks in the BlocksetEntry table. Big files have more blocks, but a file with a length but no blocks is the error. How this happens is the question. A simple test case to reproduce issues like this would be very nice to have.
EDIT: To find the actual path from that Blockset table row, you would look ID up as BlocksetID in the File table.