-
-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manually exclude titles from the batch dump process + sequential dump support (à la Hekate) + batch dump overrides #40
Comments
I suppose you're referring to the batch dumping mode? I guess a better approach to this would be adding "checkboxes" to the confirmation screen list. I don't really like to make the process depend on additional files in the SD card. If this isn't what you mean, please do tell me. I just got up, so I beg your pardon. |
my idea is to create a file contining the names of each game we sucessfuly dump Alot like hekates backup process my reasoning for this is so that we can pause in the middle of a dump when the disk is full offload the content and resume after removing the files |
I like the idea of using a file to keep track of the already dumped parts for any given dump. Should be easy to implement for XCI dumps, but NSP dumps will require some code changes because of the way they're currently generated (PFS0 header is filled after all the NCAs have been written). This is because NCA modifications change its SHA-256 checksum, which is used for the NCA filename stored in the PFS0 header. I still believe adding checkboxes to the summary list in the batch dump mode (before starting the process) is just way more user-friendly than using a file for this. |
why not just use the filename ultimately written to the disk We could also create a second directory with 0 byte files with the same name to determine what files need to be backed up. It could be a feature that is enabled in settings. Im talking about completed dumps. Not dumped parts. Dumped from internal storage. Not gamecards. |
Sure, something like that can be used to keep track of the dumped parts. I was even thinking about creating an extra file with only the PFS0 header data, but a program/script would have to be created to properly merge everything into a single NSP file in a PC. Shouldn't be difficult, though. I'll try to prepare a test version with checkboxes + sequential dump support (using the 0 byte file "checkpoint" system). I'll hopefully have it ready in the next few days. Please be aware there is stuff I'm taking care of right now in my personal life, so my progress will most likely be slower than usual. |
Awesome. Also. Ince its recomended we use fat32 it think it should default to use fat32 splitting (or only use fat32 splitting if it is indeed a fat32 filesystem. |
FAT32 support was originally enabled by default, but people began to complain about it. That's why it was disabled a lot of versions ago. Toggles for the summary list displayed in the batch mode menu are now ready in my latest internal build. I'll work on the sequential dump support tomorrow. |
Fixed in 4d44e31. |
I recomend determining what to dump by parsing a file instaid of files on the disk to determine what titles need to be dumped. This will allow multi part dumping (if you dont have a sdcard big enough to store all your dumps at once.
The text was updated successfully, but these errors were encountered: