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

Fix recovery tool empty file restore and other bugs #4991

Merged
merged 4 commits into from May 13, 2024

Conversation

Jojo-1000
Copy link
Contributor

Closes #4884

  • Fix missing block error message when restoring empty files, which were not restored
  • Fix bug when restoring backup that only contains one file with recovery tool
  • Fix path separator issues when recovering a Windows backup on Linux
  • Fix one unnecessary level of directories in restore path
  • Add unit tests for restore paths and add empty file to existing test case

Steps to reproduce (single file error)

  • Create unencrypted local backup with only one source file (test.txt)
  • Run recoverytool index . in destination folder
  • Run recoverytool restore . --targetfolder=restore

Current behavior

  • Output: Removing common prefix ...\source\test.txt\
  • Error: System.ArgumentOutOfRangeException

New behavior

  • Output: Removing common prefix ...\source\
  • No error

Steps to reproduce (empty file error)

  • Create unencrypted local backup (with at least two files) and one empty file
  • Run recoverytool index . in destination folder
  • Run recoverytool restore . --targetfolder=restore

Current behavior

  • Error: System.Exception: Unable to locate block with hash: 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
  • Empty files are not restored

New behavior

  • No error
  • Empty files are restored (without metadata like all files)

Steps to reproduce (unnecessary directory level)

  • Create unencrypted local backup (with at least two files that are not empty) in folder source
  • Run recoverytool index . in destination folder
  • Run recoverytool restore . --targetfolder=restore

Current behavior

  • Files are restore to restore\source
  • restore contains only the single folder source that could be removed from the prefix

New behavior

  • Files are restored to restore directly

Steps to reproduce (directory separators)

  • Requires Linux/macOS (Windows accepts slashes as separators)
  • Copy test backup from Windows install, or create unencrypted Linux/macOS backup and replace paths in dlist.zip with Windows paths including backslashes
  • Run recoverytool index . in destination folder
  • Run recoverytool restore . --targetfolder=restore

Current behavior

  • Files are restored without a folder, instead they have the path including backslashes as a filename

New behavior

  • Files are restored with the original folder structure

Empty files do not have data blocks stored, so don't try to get a block for empty files.
On Linux, paths were created with \ instead of / separators if backup was originally from Windows (duplicati#4884).
Also fix bug that created one unnecessary level of directories in the restore path.
Test that paths are generated correctly from a different source OS.
Also test that empty files are restored by recovery tool.
@kenkendk kenkendk merged commit ca9b48e into duplicati:master May 13, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0-byte files are not restored with RecoveryTool
2 participants