[Galaxy S II Original Android Development] Lanchon:
> I would have also expected the backup of /data to include all media/# folders

TWRP emulates the behavior of pre-emulated storage days: backing up /data never backed up /sdcard in the old days, and TWRP retained that behavior when emu was born. seems reasonable to me, and people back then would have never expected the change of behavior if they had done it differently. now i see that huge thread (https://github.com/TeamWin/Team-Win-Recovery-Project/issues/276) and realize "android, the next generation" never hacked on non-emu devices, lol. so we're all old farts now. well no surprise there... :)

anyway, there's this too:

https://github.com/TeamWin/Team-Win-Recovery-Project/issues/176

so yes, TWRP can't backup emu storage.

but a script to back up manually is hard, because on 32-bit devices, tar and other busybox apps are unable to handle files bigger than 4GB, and many times they corrupt data instead of failing. (i had an S2 phone bricked because of 'dd' wraparound killing the start of the eMMC when i was developing REPIT. thankfully, the bootloader escaped tough a hole in the data and i was able to recover.)

so really, modding TWRP should be easier than building a solution from scratch i think. ideally the patch would be pushed back into mainline TWRP.

some requirements/desirables:

- "Emulated storage" shows up as a backup option only if the device has emu storage.

- a build flag to disable said entry from showing up, just in case.

- the "Emulated storage" option should show up even if the current target for backups/restores is the emulated storage itself. this serves as a sort of documentation of what "Data" isn't in the backup context, providing a sort of solution for:

https://github.com/TeamWin/Team-Win-Recovery-Project/issues/793

- selecting "Emulated storage" for backups/restores when the current target of the operation is the emulated storage itself should fail. either you can't select the option in the UI, or the operation fails to start with a message if you try it. this would handle a concern of [MENTION=912474]Dees_Troy[/MENTION] expressed here:

https://github.com/TeamWin/Team-Win-Recovery-Project/issues/276#issuecomment-239172861

"[the] user won't pay the least bit attention to the implications of restoring a backup of media and how restoring that backup may or may not wipe out their most recent precious pictures of their newborn child."

(IMHO, users that change the target for backups/restores, have a prior emu storage backup there, and restore such a backup, cannot be consider totally clueless anymore.)

the emu stotrage option is already being added to the wipe menu, so it shouldn't be that difficult to add it to backup/restore.

EDIT:

> selecting "Emulated storage" for backups/restores when the current target of the operation is the emulated storage itself should fail.

of course this precludes using this option on devices that do not support external storage (sdcard or usb), which is not ideal. but it's a start, solvers our problem, and could be improved later. excluding the /sdcard/TWRP directory from the backup is another possibility, but it's more work (but not a lot, since code to exclude /data/media already exists). but then, what would happen if you were backing up to external? should it skip /sdcard/TWRP too? or should the semantics of backing up emu storage change depending on the backup destination? (that would be horrible!!!)