Warning message - Expected there to be a temporary fileset for synthetic filelist (...), but none was found?

This has turned up a couple of times recently when backing up to BB2, while so far subsequent backups have run with no warnings. What does it mean and can it be safely ignored?

Only since updating to 2.0.4.15_canary_2019-02-06, but that could be coincidental.

I suspect coincidental. There are many of these in the forum. Here’s an early one, with an explanation:

I think I found the bug’s source. See Expected there to be a temporary fileset for synthetic filelist #2506. Feel free to post your messages to see if you got odd names of dblock, dindex, or too-old dlist files too.

Does the idea that you had some interrupted backups appear to match your logs or your recollections?

The warning says you didn’t get the bonus visible-for-restore version based on work before interruption. Possibly you weren’t even expecting one though. Any issues arising would be from interruption, not this.

Duplicati by default verifies a sample of destination files. You can raise –backup-test-samples if you like. You can even run the test command in a job’s Commandline for all samples if you have time/bandwidth.

I don’t think a backup was interrupted; nothing in the job log anyway. Here’s the full text of the warning:

Duplicati.Library.Main.Operation.Backup.UploadSyntheticFilelist-MissingTemporaryFilelist]: Expected there to be a temporary fileset for synthetic filelist (70, duplicati-i9c3da6fcb08a4a89b804d98f8e2724af.dindex.zip.aes), but none was found?

But there is now a problem as a a verify via the GUI gives an error message “Detected non-empty blocksets with no associated blocks!”, and when I attempt a repair it finishes successfully far too quickly; and then validation fails with the same error. Now attempts to run the backup fail with the same error message.

I will recreate the database and see what happens.

The interrupted backup is the previous one. The warning is issued before continuation of backup begins.

You did indeed have the incorrect case of a dindex file being named instead of the expected dlist (filelist).

Fatal error: Detected non-empty blocksets with no associated blocks is my initial thought on this, and it’s being pursued by a lot of people. Not knowing what it is in that article, I don’t know if yours is the same…

In the end all attempts to repair/delete/recreate the database failed. As this is a duplicate subset of my main backup, in the end it was easier to delete the files (and versions thereof) and start again.

All now working again, but makes me nervous of every relying on Duplicati for my primary backups. Sorry guys.

1 Like