Purge resulted in damaged dlist files

In testing the purge command, it seemed to foul up the dlist files on the back end.

The command itself ran without error, and afterwards if I went to the restore file selector the purged folder was no longer present. Also it did free up the expected amount of free space on the back end. Great!

But when I looked at the dlist, files, they were all exactly 541 bytes. I decrypted one of them and found that the zip only contained a single manifest file with contents like this:

{"Version":2,"Created":"20190923T230024Z","Encoding":"utf8","Blocksize":102400,"BlockHash":"SHA256","FileHash":"SHA256","AppVersion":"2.0.4.29"}

Unsurprisingly, if I told Duplicati to recreate the database, it failed miserably. Well actually the operation “completed” but with 1 warning for each of the 541-byte dlist files. After recreation there are no folders shown in the restore file selector dialog. The ‘restore from’ dropdown still shows all the backup versions though.

Has this experience ever been reported before?

I haven’t verified the details about the dlist files, but I can confirm an issue with a recreate after a purge. I can’t bisect this precisely since not all the commits build, but it appears that this might have been introduced somewhere between revision e8f3bccef8da469f3b00f228a77b1965b16d0781 and 153a97285315d9562f21384365fc45b783d862ec of this pull request:

I don’t believe the issue is with database recreation. The purge operation damages the dlist files - that’s where the problem lies. Database recreation fails since it can’t work with empty dlist files.

I spent some time trying to debug this but haven’t yet found the cause…

Yes, what i meant to say was that the purge is problematic but occurs without raising an error. Performing a recreate after the purge reveals an error.

1 Like

Created a GitHub issue here:

1 Like

Thank you! I am hoping to find some time to help troubleshoot.