- init supports -pref-dir, add does not (uses current working directory)
- init supports name argument -storage-name, add uses a positional argument
Is there a reason for the discrepancy?
The storage created by init is named default, if -storage-name is not provided.
-pref-dir is being deprecated and should be avoided. Use -repository instead.
This does not address why init is using a named command-line argument, while add uses a positional argument.
Yeah, I figured it’s too anoying to divine where .duplicacy gets created given a particular combination of command-line arguments. Now I create, by hand, my one, unified, $HOME/.duplicacy/preferences with all the secrets I need inside, and all the storages for all repositories, and I have $HOME/.duplicacy also saved in a break-the-glass-in-case-of-emergency secondary location. Because otherwise, if my main disk fails, I can’t restore anything until I’ve got the .duplicacy/preferences that I just lost.
Needless to say, I only mount the $HOME/.duplicacy directory when I need to perform backups, because It contains secrets. Secrets I can’t put in the keyring / keychain because those would disappear too if the main disk fails.
Technically, you don’t need that file. You only need storage encryption password/keys and credentials for the storage itself. Saving preferences file is just a convenience, to save yourself from having to type two commands to re-add the storage on a new machine. Convenient, but far from being necessary. I would worry more about filters file, if you using one. Kopia made a great choice there to keep filters and other settings for the client at the storage. But you still need to keep credentials. that’s what password managers are for. FWIW I don’t save .preference file, because it’s implementation specific. I save just the encryption password/RSA keys to the storage. Not even cloud access credentials; they can be generated again by a cloud provider.
That’s really strange approach. How do you mount .duplicacy? With another secret? Where do you keep that secret? Make .duplicacy/* readable only by you. Problem solved. Whoever has access to .duplciacy/ already has access to your home folder anyway. Information has already been leaked.
And if you worry about malicious actor deleting your cloud backup – create separate set of keys that only can make backup but not delete anything.
Why? If main disk completely fails — you will take them from the same place you plan on keeping them at now. Likely the password manager. But until the disk fails – why not use keyring? It’s not mutually exclusive; nobody said keys can only exist in one location. After all you shall backup your keys too.
1 Like