When restoring files, if you change the “Restore from” date, all the directories you had opened while checking for files are collapsed again.
I’d like it to automatically reopen the directories I had browsed through.
If the directories/files don’t exist in the backup I’ve selected, I’d like the closest directory to be opened, and small message to be displayed.
Does that all make sense?
Right now I’m browsing through a backup checking to see if what files are a specific directory. I’m not sure how I’d use the “Search for files” tool to get what I need, and it seems like just having duplicati remember where I was would be nice.
The point is to speed up, if only a little, the browsing experience. Say you browse down through a tree to the directory that should contain the file you want to restore, but the file isn’t there. Your next step is to try a different backup date. Currently, you have to browse down through every folder in the tree again. And then again if you picked another date that doesn’t contain the file.
The link you shared would be an awesome and extremely useful feature. But I’m not sure it would cover a scenario where the file just doesn’t exist in the backup you are browsing.
That’s a valid point about the linked to proposed feature…
Thanks for your example scenario I can now see the “remember directory when switching between versions during restore file selection” feature you propose being useful.
We do need to be careful not to make a tool so “smart” it becomes cumbersome - for example, a user that wants to look at file A in the first backup but file B in the second backup would potentially have to collapse (or ignore the expansion of) the file A folder before browsing to the folder for file B.
Granted, that’s a lame comparison - browsing down to a folder is WAY “harder” than collapsing an already open one - but it’s the type of thing that should be considered.
I’d say if somebody has the time / skill to implement your idea, then they should do it. If a few more people chime in here to like your suggestion maybe it could be entered over at GitHub to draw some development time.
I know Crashplan deals with this by having a Show deleted files option, that then shows any file that ever existed where you’re currently looking. That combined with the version view then covers this scenario because you can find any version of any file from the *current* restore point.
Perhaps that would work better than having to look through each restore point until you find the right one with the file in it?
Sounds like it might. I never used Crashplan, so I’m not sure what it would look like.
I do think my idea might be easier to implement. Maybe a bit of javascript that walks back down the tree for you, if there isn’t a faster way.
The majority of the problem really lies in Duplicati’s speed issues. But from what I"ve seen of the topics and issues around that, they’re already being worked on, and they’re really difficult problems to solve. My idea might help improve things while the larger issues are being taken care of.
The emulating Crashplan’s functionality might be more complicated and take longer to get implemented.
'Course, I’m also a fan of doing it the right way the first time, so maybe my idea isn’t worth attempting if it will be superseded by better functionality down the road.
Hmm - do you think this might turn around and bite us back?
I wonder if it took you 45 seconds to dig down to the target file then you change versions would it take 45 seconds to re-expand to that location in the new version?
That’s kinda what I would expect to happen. But, you’d be able to go do something else for a bit while it loaded. Instead of having to check back and see if you can start opening the next folder in the tree yet.
If the user only has one tree open, could we put that path in the search to make it load a bit faster? It wouldn’t work if they have more than one branch of the tree open. Unless you can search for more than one file at at a time, and I just haven’t figured that out?
