Duplicati.CommandLine.RecoveryTool the tool does not create a hash file

I can’t understand what I’m doing.
I see a message that Khash will not find why?

0: d:\zzz_recovery\duplicati-20190417T204302Z.dlist.zip - Not a Duplicati file, ignoring
0: d:\zzz_recovery\duplicati-20190417T204350Z.dlist.zip - Not a Duplicati file, ignoring
0: d:\zzz_recovery\duplicati-20190417T204413Z.dlist.zip - Not a Duplicati file, ignoring
0: d:\zzz_recovery\duplicati-20190417T213024Z.dlist.zip - Not a Duplicati file, ignoring
0: d:\zzz_recovery\duplicati-b3d3546f47fe048d884ce079d73a359a5.dblock.zip - Not a Duplicati file, ignoring
0: d:\zzz_recovery\duplicati-b5f99d257d6c645248a258982a00590cd.dblock.zip - Not a Duplicati file, ignoring
0: d:\zzz_recovery\duplicati-be9676abc7e7e4e74845f7e1f295e1f27.dblock.zip - Not a Duplicati file, ignoring
0: d:\zzz_recovery\in.txt - Not a Duplicati file, ignoring
Processed 0 files and found 0 hashes

in console

Duplicati.CommandLine.RecoveryTool.exe index \
"d:\zzz_recovery" \
--indexfile="d:\zzz_recovery\in.txt" \
--full-result=true \

urgently need your help!!!

can someone tell me? What am I doing so that it all starts working?

What’s Khash? Could you expand on that if it matters (meanwhile I’ll look at the other issues)

What Windows console uses backslashes for line continuation? Nevertheless, bad continuation seems to fail differently from my exploratory testing. I did find one way to get similar symptoms, which is a path with dashes (easy to get on Windows, thanks to File Explorer’s way of naming a copy of a folder in same tree). Because I don’t have a D: drive, I tested c:\zzz_recovery and it worked. Is yours the actual path? If so, it shoots down the theory. If not, try removing special characters (especially dashes) from the folder’s name.

Are you using RecoveryTool because more ordinary ways of restoring were tried already and had failures?

I’ve not been able to reproduce this. I’ve created a folder D:\zzz_restore and copied a small unencrypted Duplicati backup to it. Then executed this command:

Duplicati.CommandLine.RecoveryTool.exe index "d:\zzz_recovery" --indexfile="d:\zzz_recovery\in.txt" --full-result=true --console-log-level=verbose

The indexfile in.txt was successfully created. This is the output:

Processing 8 files
0: d:\zzz_recovery\duplicati-20190207T081049Z.dlist.zip - Filetype Files, skipping
0: d:\zzz_recovery\duplicati-b31a88cd57d404106abb1adfdf45419e4.dblock.zip 1953 hashes found, sorting ... done!
Merging 1953 hashes ... done!
1: d:\zzz_recovery\duplicati-b722ed341cd1f4803bb2d71681063e449.dblock.zip 474 hashes found, sorting ... done!
Merging 2427 hashes ... done!
2: d:\zzz_recovery\duplicati-bd1ab9ea062db4ace8b60e4180c651af9.dblock.zip 2054 hashes found, sorting ... done!
Merging 4481 hashes ... done!
3: d:\zzz_recovery\duplicati-i2c3c9fd187374492b93c82df8bbfc753.dindex.zip - Filetype Index, skipping
3: d:\zzz_recovery\duplicati-i9ea08c075d7149c3a06b278de26f3727.dindex.zip - Filetype Index, skipping
3: d:\zzz_recovery\duplicati-id7c2364e8913490ea1a9f3f4b7393974.dindex.zip - Filetype Index, skipping
3: d:\zzz_recovery\in.txt - Not a Duplicati file, ignoring
Processed 3 files and found 4481 hashes

Were the DBLOCK files downloaded successfully? Are they all around the same size? Probably they should be around 50 MB, unless you specified a custom upload volume size.

Try renaming zzz_recovery to zzz-recovery (where the dash isn’t a leading one, so seems less likely to throw things off by being mistaken for a dash trying to start an option. On a test that worked, it now fails:

C:\>"C:\Program Files\Duplicati 2\Duplicati.CommandLine.RecoveryTool.exe" index "C:\zzz-recovery" --indexfile="c:\zzz-recovery\in.txt" --full-result=true --console-log-level=verbose
Sorting existing index file
Processing 24 files
0: C:\zzz-recovery\duplicati-20181020T002117Z.dlist.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-20181129T152527Z.dlist.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-20190103T134252Z.dlist.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-20190122T020033Z.dlist.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-20190212T005511Z.dlist.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-20190225T181956Z.dlist.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-b4093f44989a1471fb5b6fa4542e5fff8.dblock.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-b4ae114983b624c1ea0398b81bd7a3ed5.dblock.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-b4fd07fcfb03a4bebb04a2774d261b148.dblock.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-b812f881e249b457aa1e1bccc7be95672.dblock.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-b99d58aa36ae54f5aa4c089720c053094.dblock.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-bcabc416ce9194a87a7dcb95703f542dd.dblock.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-bcc2d69c7e9074184a11e664d1ab765c5.dblock.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-bfc0270b075404c2d95db6a1ccd12fe43.dblock.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-i1b3b0a8387f94e479c2cc49acc1204be.dindex.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-i2bf99c719f7946798b4f9fc59127e7e8.dindex.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-i407d46fdb51744a4945b5d082f3aa635.dindex.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-i4da95f2a1c904c1886c93014a82d9edf.dindex.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-ia15d3b280b92473bb10984bf787cf7a6.dindex.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-ia3cf696cbea249a39a18872ce1be01c9.dindex.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-ic9841cc101fc4c19b22e26690dd00429.dindex.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-ie57f55804bef4a90ac51b8499e049e5e.dindex.zip - Not a Duplicati file, ignoring
0: C:\zzz-recovery\duplicati-verification.json - Not a Duplicati file, ignoring
0: C:\zzz-recovery\in.txt - Not a Duplicati file, ignoring
Processed 0 files and found 0 hashes


and I suspect the Khash question was a typo-reword of just asking about the “found 0 hashes” at the end.

Good spot! It fails if the folder name contains a “-”. Strange, but the folder names in @rdbox 's output do conain a “_” not “-”.

I am using the pacman console msys2 with a zsh shell.
And I also run this code through the bash script file.

I tried to remove the sign "_" It does not help

1 step download

Duplicati.CommandLine.RecoveryTool  download  \
"webdavs://path_user:pass"   \
"d:\___BACKUP-CONFIG\zzz_recovery" \
--passphrase=$PASSPHRASE \
--full-result=true \
--console-log-level=verbose \
--version=0 \

2 step download

Duplicati.CommandLine.RecoveryTool index \
"d:\___BACKUP-CONFIG\zzz_recovery\\" \
--full-result=true \
--console-log-level=verbose \

in the Duplicate settings it is worth breaking the archive into 10mb
What else do I need to do, what setting?

Yes, I, too, so 1 in 1


here are my files in the cloud.


here I have already downloaded and decoded them successfully

and here the index file is empty. although there must be a file hash

Is that a dash remaining between BACKUP and CONFIG? Please try simplifying your entire pathname. Dashes are used (as you can see) in the final filename, and you’re getting complaints from code that’s trying to break the filename apart to see what kind it is. I’m not sure it’s used to seeing complete paths.

Are you set up to use the Duplicati web UI? If we can’t get the relatively obscure tool you’re using going, choosing a more usual path such as a direct restore of the files you downloaded might work instead…

EDIT more code. How’s your .NET RE expertise? To me, the overall layout looks like it expects a prefix before the first dash, normally perhaps gets the default duplicati, ordinarily forgives pathname prefix before the filename because it’s all non-dash characters, but in your case is thrown off by the dash, so therefore is confused by what follows. It’s not the usual thing that follows after the initial duplicati+dash.

Hurray earned, I made the root path d:\zzzDuplicati\recovery\
and yet I think that the duplicati program should take any path and screen different special characters.
I’m right? it may be necessary to inform the developers that they would make changes

yes i use web-ui
I’m interested in the test to see how to work console utilities. By this decided to go the hard way

I agree with the “take any path” at the UI level, but I’m not sure “screen” is exactly the right word for the fix. Possibly using the parse routine with just the filename part would be better, but it’s not up to me to decide.

These seem to clash. Experiments are great, but it sounded like you had no path at all for urgent restore.
This appears to be a bug, somehow never reported before, but you’re using a rarely-used program that’s likely more basic than things like Duplicati.CommandLine.exe. Maybe you already opened an issue on it?

If so, can you point back to this forum issue by URL, maybe test further, and post the test case to GitHub? Having all that will make a tidy package for whoever decides to take this on whenever that happens. Even though this probably isn’t the most major bug, it’s now probably much better understood than those are…

Yes, I did everything indicated on github
source from the forum as a solution.