multi-backup-targets #5
Loading…
Reference in a new issue
No description provided.
Delete branch "multi-backup-targets"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Added multi-target backup support and optimized the backup flow.
Backups can now be written to multiple enabled destinations, including local PS5 storage, USB, FTP, and the browser Drive queue for auto backups. The payload now packages the save ZIP once into a temporary staging file, then copies or uploads that same ZIP to each destination, instead of rebuilding the archive per target.
Also added per-destination progress/notifications, so backups report results like Local backup done (1/3), FTP backup failed (2/3), and final backup 2/3 done.
Reviewed — going to merge. The PASS-command rewrite is a real correctness/security improvement: replacing
snprintf("PASS %s", pass)withftp_cmd_arg(ftp, "PASS", cfg->pass, ...)doing directsend_all_fdbyte writes eliminates format-string interpretation of password characters (a password with%would have misbehaved before), and theftp_arg_has_crlfinjection guard is a nice belt-and-suspenders.Minor observations, none blocking:
BACKUP_TMP_DIR/<filename>is deterministic from save filename. Two concurrent backups of the same save (e.g. manual + auto firing on game close) could race on the.tmpwrite. A pid/timestamp suffix on the staging name would close that. Low-probability in practice.backup N/M donedoesn't name which target failed (the intermediatecloud_set_stepcalls do, but the toast-style result is just the count). Including the failed target name(s) in the final notification would help debugging./mnt/usb0as default; the existing save-scan code at L11054 / L15676 enumerates/mnt/usb0..7. Backup target could auto-detect the first writable USB instead of requiring config override. Workaround via cloud.json exists, so just a nicety.Merging.