Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backups containing a single file are not restorable #3937

drwtsn32x opened this issue Oct 5, 2019 · 3 comments


Copy link

commented Oct 5, 2019

  • I have searched open and closed issues for duplicates.

Environment info

  • Duplicati version: Affects and greater
  • Operating system: Affects Windows (not sure about Linux)
  • Backend: Any


PR #3846 seems to have introduced a bug for backup sets that contain just a single file. Backups operate ok, but you cannot restore the file. It is shown in the file restoration dialog with a folder icon and a trailing backslash.

If you try to restore it, duplicati reports "Restore completed without errors but no files were restored."

Steps to reproduce

  1. Create backup set
  2. Select a single file to back up
  3. Perform the backup
  4. Attemp to restore the file
  5. Note the failure
  • Actual result:
    Failure to restore file
  • Expected result:
    File should be restored correctly


Restore selection dialog for versions before File is displayed properly and is restorable:
Duplicati 2 0 4 21

Restore selection dialog for version and later. File is displayed incorrectly and it is not restorable:
Duplicati 2 0 4 26

Error message if you attempt to restore:
Duplicati restore error

Proposed Solution

Rolling back PR #3846 solves the problem. This original developer never identified an actual problem that the PR solved, it just seemed like a logical fix. Per the 3rd post on that PR:

There doesn't appear to be any negative consequence to the bug


This comment has been minimized.

Copy link

commented Oct 5, 2019

Thanks @drwtsn32x. I noticed the strange display in the restore tree but didn't know what the cause was. I think reverting the changes from #3846 is a good solution for now.


This comment has been minimized.

Copy link
Contributor Author

commented Oct 5, 2019

I can go ahead and submit a PR to roll back this change...thanks


This comment has been minimized.

Copy link

commented Oct 7, 2019

Thanks for tracking this down. I bumped into it but didn't pause to see if bug was new or old.

dblock put retry corrupts dindex, using old dblock name for index -- canary regression #3932

Backup two (to avoid a bug) tiny files

when writing up the steps to reproduce.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.