Memcard: Add automated rolling local backup system#14472
Draft
chaoticgd wants to merge 2 commits into
Draft
Conversation
bd647bc to
ef4e50c
Compare
ef4e50c to
eb40187
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Changes
Not yet ready for testing.
This adds an automated rolling local backup system for memory cards, as well as some new classes for handling ZIP files.
Memory cards will be automatically copied at most once a day, and older backups will automatically be deleted according to a configurable disk space usage limit.
TODO:
Rationale behind Changes
A while back there was a conversation about changing the design of the memory card busy dialog to make it harder to accidentally corrupt your memory card. Ultimately, nothing was done to it, but this got me thinking about what we could do to improve the situation.
By the time the memory card busy dialog appears, depending on circumstances it may already be too late. The game may have crashed while saving for example, so forcibly shutting it down may be the only option. Hence, modifying the design of this dialog alone would not be a bullet proof solution.
This brought me to the idea of automated backups.
I've tried to make the limitations of this system very clear in the UI, to prevent confusion:
The zip classes I'm adding were originally written for #13763 (but extended to support extracting folders from the zip, and adding them to the zip recursively). This way the classes can be integrated with our Error class. I didn't want to build on top of the existing ZipHelpers functions because they have broken error handling.
Suggested Testing Steps
Not yet ready for testing.
Did you use AI to help find, test, or implement this issue or feature?
No.