( Edit: I now think this is a bug, and changed the category and title again, sorry!
.duplicacy file (pointer file) in data folder to be backed up is used to point to a preferences folder. This works well, except when the repository setting in the preferences file is used. I think the .duplicacy file should have pesedence
This affects all commands, not only backup.)
(This is about CLI )
Thanks for an already great backup utility!
I know this has been discussed before and I believe developer has some ideas already in pipeline! But I tested a method with the current feature set.
I tested restoring to a custom folder (on same computer), using a pointer to the existing preferences path.
(If new or different computer, you need to init a repository/storage first)
A) Assuming you are not using the -repository option, this seems to work well:
- Create the custom folder you want to restore to, and create a file ‘.Duplicacy’ with the path to the preferences folder (As if you used -pref-dir, including the ‘.duplicacy’ subfolder in the preference folder) No need to init again. (limited testing though…)
- With the custom folder as working directory, issue the Duplicacy commands for list, restore (add pattern to specify what you want) etc.
- When done, remove the file ‘.duplicacy’ from the custom folder
B) But let’s say the preferences folder was init’ed with option -repository pointing to the ‘real’ folder to be backed up. (I am using this as my preferred setup). Now, even if you issue the restore command from a custom folder with a .duplicacy pointer to preferences, the repository settings in the ‘preferences’ file overrides and will cause the restore to write to the original backup folder instead of the custom you want.
To work around this, I can either
- Temporarily remove the repository line from the preferences section for the storage, and add it back after restore
If a backup job is scheduled to run at this time, that backup will now use the (empty) preferences folder.
Also, forgetting to re-apply the setting (problem in users script? or forgetfulness) will cause later problems
Or I can:
- Copy the preferences folder to a temporary folder, and remove the repository line from the ‘preferences’ files.
CONs: The cache folder might contain a large amount of chunks, which now takes double space on your disk.
If you instead copy without the cache, downloads might incure delays/cost. (not a problem with local backup storage)
But at least this does not disturb the original preferences file and backup jobs
May I suggest that
.duplicacy -pref-dir file get priority over the repository setting in the preferences file.
This would be enough to solve my problem without having to duplicate or manipulate preferences.
For completeness, and ease of use, the restore command could also get the -repository option to override configured repository (backup) folder.
(-restore-to has been suggested but I feel -repository is more consistent, corresponds to the similar option in init and add. But the name of the option is not very important to me )
I then suggest this priority if several config options are present:
- Commandline: restore -repository path (highest presedence)
- .duplicacy file with preference path in current folder
- Repository setting in the preferences file
(Perhaps existing files in the (real) repository could still be used as chunk sources!)