This questions is relevant both for the CLI and the GUI version.
How can I search for a particular file name (or parts thereof)
- within a single revision?
- across multiple/all revisions?
If you know the exact file name, then the history command is the best option:
duplicacy history -r 12 path/to/file
duplicacy history -r 1-100 path/to/file
Otherwise, use the list command and grep:
duplicacy list -r 12 -files | grep pattern
duplicacy list -r 1-100 -files | grep pattern
Not sure how to do that on windows…
But even so: it looks like i’ve found the big minus for duplicacy. Can we expect to get that search function as part of a proper restore interface in the GUI? It’s extremely cumbersome having to search for one or multiple file paths using CLI and then basically having to re-enter them into the restore interface. Even if I’d work with CLI only, it’s not possible to do a search and then say: yes, please restore that file?
Not to mention that I have to lookup the relevant revision numbers (because, usually, you want to search a particular time frame rather than particular revisions)…
Edit:
OK, I figured out that the search function already exists, at least in the latest GUI beta 2.1, but you have to know your search wildcards and you can only search within one revision at a time. Any chance that search across revisions will become available?
Also: I miss the possibility to restore a file to a different location. I was sure that once I clicked “restore” I would be asked where to restore it to, but this was not the case so I frantically had to stop the process to prevent stuff from being overwritten.
1 Like
I think if we allow the history command to take a wildcard pattern then it can be used to search files within a range of revisions.
In beta 2.1 to restore to a different location you’ll need to initialize a new repository on the new location with the same repository id. This is more inline with the CLI usage. I’ll update the GUI user guide once the beta becomes more stable.
But why not let let the user choose whether the files(s) in question should be restored to the original location or somewhere else? Any backup program I know does that. Why insist on the original location, going even so far as to force the user to initialize a new repository with the same name if the old one no longer exists?
It is just a matter of providing a -restore-to option to the restore command. It is my personal preference not to implement this option for simpler logic and a unified way of restoring files. Initializing a new repository before running the restore command isn’t too bad, and it is actually less error-prone than the -restore-to option.
I’ll steal this thread to say that i also think duplicacy should let us restore wherever we want to, not only to a new (empty) repository. From a usability perspective, this seems like a better use-case.
I’m not sure if I understood the difficulty of doing the restore to a different location. I’ve done this several times!
Of course it would be great to have the -restore-to option, but it is perfectly possible to do the restore to any desired location without it.
I use the settings in a centralized folder (the -pref-dir option), then in each repository there is no duplicacy folder, cache, keyrings, etc., only a small file with one line: the path to the settings folder.
So when I want to restore something to a different folder I just copy that little file (or create, it’s just a txt file with one line) to the new folder and run duplicacy restore.......
If I understood correctly, is this what you are talking about?
You might as well link to your more detailed explanation of your setup here 
Thanks for those explanations. It sounds like your setup should be described in all necessary detail in the duplicacy instructions as a kind of step-by-step guide. I believe it’s a wiki, so you could do other users a great favour by adding a page about “central vs decentral preference directory” or something like that.
The thing is, it takes quite a bit of thinking and trying out to wrap your head around how your setup works in practice (as simple as it may be, once you’ve understood it).
Currently, when you read the instructions for the init command, you only get an innocent note that “the -pref-dir option controls the location of the preferences directory”. The potential use case for this is not at all clear…
Having said that, I’m still in favour of a -restore-to option.
One thing I’m still wondering about: the instructions for the init command state that
Once a storage has been initialized with these parameters, these parameters cannot be modified any more.
Does this mean that it is also impossible to switch to different pref-dir once you have initialized a repository without the pref-dir option?
It sounds like your setup should be described in all necessary detail in the duplicacy instructions as a kind of step-by-step guide.
It sounds like a good idea. I’ll do this in the next few days, with Gilbert’s permission.
adding a page about “central vs decentral preference directory” or something like that.
I really don’t see any advantage in keeping the settings within each repository (decentralized), but maybe I have not noticed something and Gilbert can explain why.
One thing I’m still wondering about: the instructions for the init command state that…
Actually, although my backup jobs are working as expected, I still have not completely mastered the init command. I have doubts (as you can see here), probably related to the application of the nomenclature (repository, storage, etc), and I remember seeing some time ago on some topic here someone commenting on the nomenclature.
I really don’t see any advantage in keeping the settings within each repository (decentralized),
The only evident advantage I can think of is that you don’t have to specify/remember any specific place. Everything is in the base folder of the respective repository.
Duplicacy is largely modeled after git/hg. And I found it is convenient and less error-prone to have all settings saved under the .duplicacy directory. I understand that some of you have a different view, but my plan is to gradually introduce new options to support all usages eventually without dramatically changing the current model.
@towerbr or anyone else, feel free to create or edit any wiki page. The wiki is open to edits by everyone.
Once a storage has been initialized with these parameters, these parameters cannot be modified any more.
This applies only to the 3 chunk size parameters. The pref-dir can be freely modified (by hand) any time.