For automating unattended backups with Duplicacy CLI I feel it would be convenient to pass the “repo to be backed up” as a parameter to the backup command, rather than requiring the working directory to be the repo itself. Obviously I would not ask that the current working directory functionality be removed, only that something like duplicacy backup -repo /path/to/repo be an option that is supported in addition.
Giving it a second thought, I’m not sure how exactly this would be superior to the working directory functionality (or if in fact it would indeed be superior at all), but something about the need to ensure that a backup task is run from the correct directory strikes me as a potential source for error.
The -repository option of the init command allows you to set up a ‘pseudo’ repository and the actual directory to be backed up can be different. Is this what you want? You’ll still need to change the current working directory to this pseudo repository before running the backup.
This is how I have my repos set up (I have a number of ‘pseudo’ repositories all set up at /backup/repos/repo1, /backup/repos/repo2, et cetera). Thank you very much for adding the -repository option for the init command, that’s actually what inspired this request!
For crontab purposes, rather than prepending cd /backup/repos/repo1 && (or similar) to the head of each duplicacy backup cron job, and rather than writing a short wrapper script that takes a repository path as an argument (and then cds to that path before initiating the duplicacy backup job), I’m requesting that users be able to pass the repository path directly to the backup command, e.g. duplicacy backup -repository /backup/repos/repo1.
I guess when you really break down this request to its core, what I’m actually asking for is a backup command option -repository </path/to/repository> that would shift the burden of responsibility for changing the current working directory onto Duplicacy itself rather than onto the user (or the user’s automation).
This is not a very high priority issue for me, but I think it could possibly help clean up various cron jobs a little.
Yes this is precisely what I was thinking with this request, that it would be a small quality-of-life improvement for scheduling duplicacy backup jobs in crontab.
-repository is already in use. (Indicating to init the “real” folder to back up)
What you want to point to is the preferences folder for this backup. Not sure what a good name would be, but since it replaces a CD command, maybe it could be called -cd ?
(-prefdir is also a bit different.)
I think that would make sense, and is a great idea.
That’s a good point. The idea of a -repository option for the backup command came up to me because “repository” was the concept that made the most sense when considering what the backup command is actually doing, but you’re right that the init implementation has a completely different context than the one I’m thinking of. It’s kind of a shame, because I feel like the directory containing a .duplicacy prefs dir is actually more of a “repository” than the init-specific usage, but I would not want to create the possibility of ambiguity or confusion.
I’m curious if others feel the same way, that having duplicacy init -repository have a different/unique meaning compared to a hypothetical duplicacy backup|restore|list|check|prune|add -repository would be a strong enough reason to choose another name for the option?
Hi, I’m changing my mind on this, I now agree with you on -repository option to specify (or override default) repository!
(Based on my meandering thoughts here:)
You could use a .duplicacy file to point to the preferences from the repository folder but of course that’s not quite what you are after!
I don’t think there is a conflict, because:
For init and add commands, -repository option indicates repository to use as default, and is stored in preferences file. This is then used by all other commands using this preferences file.
I support your idea of a -repository option for the other commands, to override the default repository setting in preferences or .duplicacy (-pref-dir) file. Especially useful for the restore command, to easily specify a custom folder!
(Edit: This would apply to commands that needs to know the repository, like backup and restore, probably not copy, prune, list etc that access backup storages)
I suggest this priority for selecting repository folder if several config options are present:
Current folder if .duplicacy file is present (in -pref-dir format). (Overrides repository setting) (bug reported above)
Repository setting in the preferences file if no .duplicacy file in current folder. (this probably means you are running from a standard repository with .duplicacy preferences folder in it)
My apologies @roland.cassini, what you seek is a way to specify the parent of the preferences folder on the command line, so I cannot use your use case to promote my case for -repository (pointer to data folder)!
You know this but just for summary: Your example repo1 folder is a “pseudo-repository”, and holds the preferences folder “.duplicacy” which holds all the settings, passwords for storages, cached chunks etc. for repo1, including the setting for repository path.
Most, if not all, commands needs to know where this preferences folder is. Easy in Windows Task Scheduler but maybe not so much in other OS, or one might like the option.
Perhaps a good name for a new option could be -preference, or like @Droolio suggested: -cwd
If considered, developer must decide if maybe it should be a global option for all commands, e.g.: duplicacy -cwd <path to .duplicacy folder> command [more options]
from a standard repository with .duplicacy preferences folder in it)