The best way to handle these is to delete dindex and let Repair upload it again, provided the database still has needed information which can be lost if the database is recreated from destination that’s already bad.
The affected command doesn’t appear to handle dindex files with the nice output it produces for dblock. There’s a similar non-result (at least for me) for The LIST-BROKEN-FILES command for missing dindex.
There may be room for enhancement in the tools. You could open an issue to track, but backlog is larger than available resources. Anybody able to help with Duplicati in any way (including forum) is encouraged.
That might be oversimplifying. A given version’s blocks can move to different dblock files due to compact.
EDIT:
and although the initial creation of a version uploads a specific set of files, they are just the changed parts, meaning the blocks already on the destination in other dblock files are referenced and not uploaded again.
Every dblock file ordinarily has a dindex file to index its contents, however I’m not sure of any easy way to map an index file name into its associated dblock file name for use with the usual damage-analysis tools.
A not-easy way is to open the database with a browser such as DB Browser for SQLite and work with the Remotevolume and IndexBlockLink tables. In below, volume 4 dindex file goes with volume 3 dblock file.
