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 \
--console-log-level=verbose
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:
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
C:\>
and I suspect the Khash question was a typo-reword of just asking about the “found 0 hashes” at the end.
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.
@ts678
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…
