garethgeorge
commented
1 week ago I agree that backrest unexpectedly modifying the restore path is odd behavior and it's something I'll go ahead and cleanup in the release with a few changes
- Better defaults populated in the UI when opening the restore dialogue
- The path is accepted on the backend w/o modification, if no path is provided Downloads folder is used
I'm open to restore in place now that Backrest is 1.0.0 but I think this is probably a new capability that needs some feature work and significant attention re: validation and test coverage. It's not high priority at the moment for me but I'll leave this open to track.
Currently the restoring to path option creates an additional "restic-restore-xyz" directory under the specified path. As mentioned in #118 this is done to prevent potentially unwanted destruction of data. This however is not reflected by the UI leading the user to expect backrest to restore into the specified path which, in my eyes, would be the desired behavior anyway.
Not restoring a backup in place requires a full additional copy before its data can be moved to where its supposed to be. Requiring double the space on big backups is not exactly great.
Not wanting to disregard the original intent with the current behavior I suggest a simple "is the provided path empty"-check combined with a warning dialog and maybe have a "safe" path as a default.
If non of this seems acceptable for now I suggest putting the generated directory name behind the "Restore to path" text input to make it visually consistent at least.