Duplicati stuck in Compaction

ts678 · March 17, 2025, 10:15pm

Pretty new. The link I cited gives (further down) the date and the 2.0.9.109 note.

The pull request cited in above link gives explanation, but it’s long and technical.

Direct link:

github.com/duplicati/duplicati

Fix issues with extra blocks and files being recorded after an interrupted `Compact()`

master ← feature/fix-compact-disruption-test

opened 02:11PM - 01 Nov 24 UTC

kenkendk

+803 -191

As identified in #5184 if the compact process is interrupted, the local cache vi…ew of the remote storage gets slightly distorted. The reason for this is that the blocks are moved from the old to the new volume in the database. If the process completes, the old volume is deleted and all is fine. But if the process is interrupted, the old file is recorded as having only the remaining blocks, but it has not been modified, so it actually has all the blocks still. If the verification process is started, the results here will show that the block file has "extra" data. This PR changes the logic slightly, so each newly created volume will be assigned duplicated blocks, meaning the old volume stays the same through the process. If the process is interrupted, the old volume is still fully registered in the database, and the verification works. The new file has duplicate blocks, but these are also recognized and no errors happen. When the compact is completed, the old volumes will be deleted. Before this step is performed, any blocks that are to be lost from the old volume being deleted are selected from the duplicated blocks. These blocks now point to the new volume and the old volume is marked as deleted. This fixes #5184

I like fixes, but the price of this one is pretty high, and I hope it can be reduced.