Restoring from encrypted repository fails with no/misleading guidance if `-e` is not passed to init

Wow this is crazy. This is SO NOT intuitive. Plus it doesn’t work right.

If you try to create a new respository in your example just to be able to restore to a different directory it fails with the following:

Failed to download the configuration file from the storage: The storage is likely to have been initialized with a password before

You really need to consider a “restore to option”. I’m sorry but this is absolutely crazy :frowning:

1 Like

This error has nothing to do with usability, or restoring to a different location - either your password is wrong, or you’re doing something else wrong which results in this error, such as not supplying or enabling an encryption password.

In most cases this should be

duplicacy init backup1 sftp://user@192.168.1.100/path/to/storage -e
                                                                ^^^^

Took me half an hour to figure out why it wasn’t working. Maybe for people working with duplicacy every day it is obvious that you need to tell duplicacy to encrypt the storage, but for the average user?

Quick suggestion: when the user tries to initialize an encrypted storage without the -e option, instead of just saying

Failed to download the configuration file from the storage: The storage is likely to have been initialized with a password before

say:

Failed to download the configuration file from the storage: The storage is likely to have been initialized with a password before. In that case, use the -e option.

Or even better: just assume -e and ask for the bl@#%y password!

3 Likes