'Invalid hash key' error at backup completion

Bug
#1

I just started with Duplicacy (trial version) and Backblaze B2 cloud storage (staying under 10GB of total backup size while testing, so still free). (Because: CrashPlan)

I’m Windows 10 x64 ver 1709. I’m using Duplicacy x64 ver 2.1.0. I made 3 jobs, each a single folder and am backing up all 3 jobs to the same Backblaze bucket.

For two out of the three backups, I got a “Duplicacy Error - ERROR Invalid Hash key.”

Here’s the entire log portion for one of the errored backups - this one happened to be one large PDF file, so the log is short.

invalid hash key

What does this mean, and what should I do about it?

#2

This is a design negligence. The snapshot file is encrypted with a key derived from the path of the snapshot file. The snapshot file path consists of the hostname, the last component of the repository, etc. In your case the snapshot file path is longer than the maximum length that a key can be and that is why it complained about “invalid hash key”.

I’ll roll out a new beta shortly to fix this bug.

#3

Beta 5 available from https://acrosync.com/duplicacy/duplicacy_installer_win64_2.1.0.exe should fix this bug.

#4

Thanks gchen. I installed Beta 5, deleted the files in my B2 storage, then backed up one of the repositories with a long path again. This time I got a different error. In the Duplicacy log file, at the end there are several lines like

… backblaze ‘returned status code 400’

Then ‘Incomplete snapshot saved to…’

Then a Duplicacy error dialog popped up
‘…Backup operation returned an error: program exited with status code 100’
and there’s a red “!” on my Duplicacy tray icon.

#5

I have now completed my other two test backup jobs. The other long-pathname job gave the same error as above. The job with a short pathname, which completed successfully on my first test yesterday, completed successfully again.

On the two long-pathname backup jobs that failed, I just noticed another anomaly: Before the ‘Incomplete snapshot saved to…’ log entry, there is another log entry
'…ERROR_UPLOAD_File Failed to upload the file snapshots … Maximum backoff reached.

#6

The 400 status code is caused by spaces in the repository path. But this should have been fixed in Beta 5. I tested with a really long repository path with spaces and didn’t have the error.

Can you remove the .duplicacy folder under the repository, and then delete and recreate the job? With Beat 5 this would use a new repository id with spaces being replaced by ‘_’ and this issue should not occur any more.

#7

I deleted the .duplicacy folder in one of the failing repositories that has a long name and spaces. I right-clicked on the corresponding tab in the GUI and deleted the job. Then I recreated the job. Same result - status code 400 errors.

Just in case, I deleted the .duplicacy folder and the corresponding job for the other failing repository with long name and spaces. Then I quit Duplicacy, rebooted the PC, then started Duplicacy and recreated the job. Same result - status code 400 errors.

Oh, and I verify it says Beta 5 in the Duplicacy title bar.

#8

What is the value of “id” in the .duplicacy\preferences file? Does it contain spaces?

#9

I don’t think so.

This is the id value for the job that completes successfully.

“id”: “HP13-AD173CL-John-AWA”,

This is the id value for a job that fails.

“id”: “HP13-AD173CL-John-Mallory_Radio_Service_Encyclopedia,_5th_edition,_Apr_1946”,

#10

All I can see is that the successful job ID value contains no underscores. And that the unsuccessful job ID value contains underscores, but also contains “,_” in two places. No doubt because the folder name contains commas. The other failing job is also of a folder that contains a comma.

#11

I thought I was on to something. I deleted the job, removed the commas from the folder name, and recreated and ran the job. Same status code 400 errors.

#12

I can confirm it is the comma that caused the problem. If you download from the same link it will become Beta 6 for which spaces and commas are removed from the repository id. But again you need to remove the job and the .duplicacy folder as well. On the storage password dialog where you’re asked to enter the storage password, you’ll see the automatically generated repository id which shouldn’t contain spaces and commas.

#13

I downloaded and installed Beta 6 (confirmed in title bar). I deleted the .duplicacy folders, and the corresponding jobs, the two jobs that failed previously because of spaces and commas. I recreated the jobs. I confirmed that the repository IDs that displayed in the encryption password dialog did not have any spaces or commas.

One repository, which contains one large PDF file, now completed successfully.

But the other repository, which contains a much smaller amount of data (70 MB) but a very large number of files and folders (thousands), failed again. The same status code 400 errors, and snapshot errors, in the log. And the Duplicacy error about ‘program exited with status code 100.’

So I deleted the .duplicacy folder and the job for this repository again, and recreated again. I again confirmed that the repository ID that displayed in the encryption password dialog did not have any spaces or commas. I looked in the .duplicacy folder and saw that the ID looks good. Here it is:

“id”: “HP13-AD173CL-John-Bunis\u0026Kaczowka-AntiqueRadiosCombinedEdition”,

But it failed again, in the same way.

#14

Oh but what about that “\u0026” in the ID? It replaces an ampersand ("&") in the folder name. Is it OK?

#15

“\u0026” is just the unicode for “&” but I don’t know why “\u0026” is shown instead of “&”.

You can edit the preferences file to remove “\u0026” as a workaround. I’ll work on Beta 7 to fix this issue.

#16

I edited the preferences for this job, changing \u0026 to &, but the job still failed in the same way - status code 400, etc., errors.

This backup is just a single folder (with lots of subfolders and files). It’s about 70 MB in size. There’s nothing private in it. I could make it available for you to download and test with if you wish.

#17

Don’t change it to &. Just remove it. The repository id shouldn’t have non alphanumeric characters except ‘_’ and ‘-’.

#18

I removed the “&” and the backup completed successfully.

#19

Thanks for Beta 7! I tested it with a special “torture test” folder (repository) that I made with many bizarrely named subfolders (and sub-subfolders, etc.) and files, and really long path lengths. It appeared to get backed up successfully with no errors.

So, I have given Backblaze B2 my payment info in preparation for uploading hundreds of GB via Duplicacy. But I have more questions about Duplicacy, so expect to hear more from me in another thread or two later. Thanks again.