Duplicati.CommandLine.RecoveryTool.exe fails single-file restore if --targetpath is used

[ts678]

• I have searched open and closed issues for duplicates.
• I have searched the forum for related topics.

---

Environment info

• Duplicati version: 2.0.7.100 Canary and earlier
• Operating system: Windows and Linux
• Backend: N/A

Description

Using --targetpath with RecoveryTool for single-file restore fails in Removing common prefix step, giving message starting with:

error: System.ArgumentOutOfRangeException: startIndex cannot be larger than length of string.

Steps to reproduce

1. Backup a short file.
2. Use RecoveryTool steps, e.g. as documented around Restoring files using the Recovery Tool to restore it using a --targetpath.

• Actual result:
  Fails as noted above. See details below.
• Expected result:
  Works

Example:

C:\Program Files\Duplicati 2>mkdir \tmp\recovery_work

C:\Program Files\Duplicati 2>mkdir \tmp\recovery_file

C:\Program Files\Duplicati 2>Duplicati.CommandLine.RecoveryTool.exe download "file://C:\Duplicati\duplicati-2.0.7.100_canary_2023-12-27\RUN\test 3\\" C:\tmp\recovery_work
Listing files on backend: file ...
Found 3 files
0: duplicati-20240118T213530Z.dlist.zip - downloading (649 bytes)... done!
1: duplicati-b2d60dba739d645adb98f522a6d89ad72.dblock.zip - downloading (751 bytes)... done!
2: duplicati-id62e5faa937644a2b2dde8b3a484cf9d.dindex.zip - Filetype Index, skipping
Download complete, of 3 remote files, 0 were downloaded with 0 errors

C:\Program Files\Duplicati 2>Duplicati.CommandLine.RecoveryTool.exe index C:\tmp\recovery_work
Processing 2 files
0: C:\tmp\recovery_work\duplicati-20240118T213530Z.dlist.zip - Filetype Files, skipping
0: C:\tmp\recovery_work\duplicati-b2d60dba739d645adb98f522a6d89ad72.dblock.zip 3 hashes found, sorting ... done!
Merging 3 hashes ... done!
Processed 1 files and found 3 hashes

C:\Program Files\Duplicati 2>Duplicati.CommandLine.RecoveryTool.exe restore C:\tmp\recovery_work --targetpath="C:\tmp\recovery_file"
Using set 0 with timestamp 1/18/2024 4:35:30 PM
Building lookup table for file hashes
Index file has 3 hashes in total
Building lookup table with 2 entries, giving increments of 1
Computing restore path
Restoring 1 files to C:\tmp\recovery_file
Removing common prefix C:\backup source\short.txt\ from files
 error: System.ArgumentOutOfRangeException: startIndex cannot be larger than length of string.
Parameter name: startIndex
   at System.String.Substring(Int32 startIndex, Int32 length)
   at Duplicati.CommandLine.RecoveryTool.Restore.MapToRestorePath(String path, String prefixpath, String restorepath)
   at Duplicati.CommandLine.RecoveryTool.Restore.Run(List`1 args, Dictionary`2 options, IFilter filter)
C:\Program Files\Duplicati 2>Duplicati.CommandLine.RecoveryTool.exe download "file://C:\Duplicati\duplicati-2.0.7.100_canary_2023-12-27\RUN\test 3\\" "C:\tmp\recovery_work"

C:\Program Files\Duplicati 2>del "C:\backup source\short.txt"

C:\Program Files\Duplicati 2>Duplicati.CommandLine.RecoveryTool.exe restore C:\tmp\recovery_work
Using set 0 with timestamp 1/18/2024 4:35:30 PM
Building lookup table for file hashes
Index file has 3 hashes in total
Building lookup table with 2 entries, giving increments of 1
Restoring 1 files to original position
Removing common prefix C:\backup source\short.txt\ from files
0: C:\backup source\short.txt (94 bytes) done!

C:\Program Files\Duplicati 2>

Fastest way to restore part of a backup shows removing --targetpath avoids this on Linux.
Inconsistency in file size on restore shows the same for Windows, and above that, the suspected problem with the code is discussed.

EDIT 1:

I tested with a two-file backup of A.txt and B.txt (containing that letter), and confirmed that it fails if restoring just one file.

Screenshots

Debug log

[duplicatibot]

This issue has been mentioned on Duplicati. There might be relevant details there:

https://forum.duplicati.com/t/fastest-way-to-restore-part-of-a-backup/10849/22

[fluidum]

Same issue with duplicati-2.0.7.1_beta_2023-05-25 on Windows 10.

At least its possible to restore files directly to root of drive where unencrypted indexed files are without using --targetpath parameter.

[Jojo-1000]

This has been fixed in #4991 but not yet merged.