Feature request: make "Storages" first-class objects

Feature
#1

This would be a useful feature for the CLI, as well as any GUI. Currently, the storage settings are specific to each job. A storage can have a name, but that name is still “local” to a specific job. This means that, in the fairly common case when several jobs use the same storage (such as when creating a separate “restore” job), you have to re-enter the storage settings for each job. This is especially frustrating setting up storage requires sensitive information (like API keys) that might be hard to find.

It would be nicer if storages, like jobs, were “top-level” objects that only have to be set up once per computer, rather than once per job. Then, when creating a job, users would reference one or more existing storages by name - or, in the GUI, choose them from a pop-up menu or similar.

As an added bonus, this can simplify the common situation where multiple devices are backing up to the same storage. If the list of storages was kept in its own file in the .duplicacy folder, then you could presumably copy that file and the keychain file between devices, thus setting up storages only once for use on multiple devices.

1 Like
#2

Storages in the web-based GUI work just like that – each storage has a unique name and when you create a job you can reference the storage by its name. However, for the CLI if you want to do the same you’ll need a centralized location to store storage settings, which introduces extra dependency on a directory outside of the repository. This may not be a good idea in my opinion.

1 Like
#3

I also don’t think it’s a good idea.

1 Like
#4

Hmm, I see what you mean about creating an extra dependency, and why that might be a bad idea. I think you’re right - this might add complexity that’s not currently justified.

Having said that… just to play devil’s advocate, I would point out that many, many other CLI tools that primarily store settings per-repo or per-project, like git and npm, also have the option of per-user or per-system global settings. I don’t think it would be unreasonable for Duplicacy to do the same thing, although there may not be a compelling reason to do so quite yet.

As an alternative, will any of the following work?

  1. If I want to restore to an empty directory instead of into the repository, can I simply cp the .duplicacy file into a new, empty directory, then run a restore there?
  2. If I want to back up two repos on the same computer (or two repos on two different computers), can I copy the .duplicacy directory from one to the other and have the backup work correctly?
  3. If the above are possible, will it work with all settings, or only with some settings? Will it work on all platforms (for example, will it work on Macs where the system keychain is used, and also on Windows where a keychain file is placed in the .duplicacy directory?
#5

Yep!

Almost. You need to change in .duplicacy/preferences the line id to a new name (i think it’s id, could be wrong here – Try It And See) and you also have to copy the authentication file (eg. for gdrive).

To this i cannot answer :-?.

1 Like