# Release: 2.1.0.119 (Canary) 2025-05-29 **URL:** \ **Category:** Releases\ **Created:** [May 29, 2025, 6:20am UTC](https://forum.duplicati.com/t/release-2-1-0-119-canary-2025-05-29/20715 "2025-05-29T06:20:20Z")\ **Posts on this page:** 1\ **Page:** 5
**Author:** ![ts678](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@ts678](https://forum.duplicati.com/u/ts678)\ **Post date:** [September 27, 2025, 12:17pm UTC](https://forum.duplicati.com/t/release-2-1-0-119-canary-2025-05-29/20715/81 "2025-09-27T12:17:24Z")
> [@kenkendk](#): > > > [@Taomyn](#): > > > > ```plaintext > > duplicati-b4b09349f34e34766931ca770d5c16c94.dblock.zip.aes: 1 errors > > Extra: +0nAIzGYf+Dk4B5xdkLE+YwhcJKZTXeQ/edh+51aQ24= > > > > ``` > > This is not fixed by the repair command. It happens due to to a bug that has been fixed, where the same chunks (from a blocklist) could be written to multiple `.dblock` files. When this happens, the database will only track a single one of them, and report all the others as “extra”. > > Generally, you can ignore “extra”, as it means that there is **more** data in the file than what was expected. > > > [@Taomyn](#): > > > > `The empty index file duplicati-i836147d0459948d4a5d7663528f26aab.dindex.zip.aes is larger than expected (54541 bytes), choosing not to delete it` > > This is a file that is most likely not needed. The database has no entries for the file, so it should be safe to delete. But because it is not an empty file (due to the size) it is not deleted. @Taomyn do you know if you deleted it? I was trying to clean an old backup in 2.1.1.103 and ran into both situations. My excess dindex files compared to dblock have been at 18 quite awhile, and I even have an 18 coded into a post-backup checker to allow difference. Looking at my 18 files, 17 were highly empty (541 bytes encrypted) with only a `manifest` file. The other dindex actually pointed to a dblock in its `vol` file, but dblock does not exist, which raises the question of whether the dindex file has any value to keep, yet it is kept… [Delete empty index files #6066](https://github.com/duplicati/duplicati/pull/6066) looks like it gives the LargeEmptyIndexFile warning if file size is \> 2048, but an enhanced version would consider the situation more carefully. If the support response to this will be “should be safe to delete”, maybe the code should delete it, especially for known damage. What it does for me is delete the very empty dindex files that cause no Duplicati problem, while leaving the invalid dindex file that I think is the cause of recreate complaints such as ```plaintext Warnings 3 2025-09-26 22:14:12 -04 - [Warning-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-MissingFileDetected]: Remote file referenced as duplicati-b0a036e8f4a4d413887a64aa2e8e0119d.dblock.zip.aes by duplicati-i3d50ab7aa9384ceb8593fe0c8733150e.dindex.zip.aes, but not found in list, registering a missing remote file 2025-09-26 22:23:11 -04 - [Warning-Duplicati.Library.Main.Database.LocalRecreateDatabase-MissingVolumesDetected]: Replaced blocks for 1 missing volumes; there are now 1 missing volumes 2025-09-26 22:25:54 -04 - [Warning-Duplicati.Library.Main.Database.LocalRecreateDatabase-MissingVolumesDetected]: Replaced blocks for 1 missing volumes; there are now 0 missing volumes ``` It would be interesting to know if your bad dindex is similar. If around, it can be opened up. On the “Extra” issue, a `test` with `full-remote-verification` was giving 633 errors, so was getting tiresome to view. I wound up runnng a database recreate to cut amount down. Actual testing was in 2.1.1.103\_canary\_2025-09-25 and 2.1.2.0\_beta\_2025-08-20, but my Google search for the “choosing not to delete” turned up lots of Canary, and this response. [Previous page](https://forum.duplicati.com/t/release-2-1-0-119-canary-2025-05-29/20715.md?page=4)