4

I am able to backup my app's data from the root/data/data/you.package.name directory by just moving it to SD card manually. however, when i reverse the process, AKA paste the data back to simulate a restore, the app just force closes, i have tried it with a bunch of apps and noticed the same reaction. Where am i wrong?

copper girl
  • 51
  • 1
  • 2
  • 1
    Permissions messed up I suppose. Don't copy into SD card directly but make a tar archive which preserves permission of source files (app's data). Restore data in such a manner that it restores the same permissions, restore SELinux context (in case SELinux is in enforcing mode). BTW, which Android device and version are you using? – Firelord Mar 18 '16 at 04:16
  • Also, before restoring, make sure the app whose data you're trying to restore is completely stopped. Do so using command-line or Settings app. Also make sure you clear its data before restoring yours. Perhaps my answer can help here: Backup an app's complete data when phone is stuck in bootloop – Firelord Mar 18 '16 at 04:17
  • permissions are only required for the system folders my dawg not user data my homie told me – copper girl Mar 18 '16 at 04:21
  • Whatever your homie told you, @Firelord is right: /data/data uses an EXTFS file system allowing for granular permissions and ownership, while SDCard uses FAT which does *not* allow for that. By copying to SD you "disowned" the files. After having copied them back, they had the wrong ownership, so the app becomes unable to access (or even overwrite) them. Unable ro read/write its data, it crashes then (expectable behaviour). // See our backup tag-wiki for how to do backups. Helium or adb backup are there for this kind of job. – Izzy Mar 18 '16 at 08:08
  • @Izzy I feel quite odd by correcting you, but any mountpoint listed under /storage is a FUSE, not a FAT. – Grimoire Mar 18 '16 at 14:24
  • 1
    @DeathMaskSalesman True it's FUSE, but AFAIK it acts like FAT (compatibility stuff). What file system is FUSE, please? :) It's not a physical file system on its own, but rather an implementation (FUSE stands for File System in User Space, which opposes the "System Space" aka "kernel space"). There're several file systems using FUSE: SSHFS, DAVFS and others have FUSE implementations. For details, see e.g. Wikipedia: it's a "virtual file system" providing a "bridge" to the actual kernel interfaces. – Izzy Mar 18 '16 at 14:47
  • @Izzy Nice point. You're correct. – Grimoire Mar 18 '16 at 14:50
  • 1
    @DeathMaskSalesman Firelord just offered proof: sdcard program does the job of mounting FUSE and in config.jd is mentioned that the sdcard program is used by some devices to expose internal storage through FUSE. – Izzy Mar 21 '16 at 10:33

1 Answers1

5

As there's no more feedback, I'll sum up from the comments for those coming up with a similar issue:

Firelord correctly pointed out this most likely is an issue with file permissions. Internal storage uses a file system supporting granular file permissions1 – which are not supported by the file system used on SD cards2. So the copy of all the contents on your SD card has lost that information, and ownership got lost3. So copying this back to your internal storage, it still has the wrong ownership, so the app cannot access it properly. Not expecting this4, the app will of course misbehave: an exception will occur without being handled, so the app crashes (force-close).

For those who checked with the mount command and now argue you're wrong, SD card doesn't use FAT but FUSE! – True it's FUSE, but in this case it acts like FAT. What file system is FUSE, please? :) It's not a physical file system on its own, but rather a virtual one (FUSE stands for File System in User Space, which opposes the "System Space" aka "kernel space") providing a "bridge" to the actual kernel interfaces. There're several file systems using FUSE: SSHFS, DAVFS and others have FUSE implementations. Again it was Firelord bringing up some backing to my claim: sdcard program does the job of mounting FUSE and in config.jd is mentioned that the sdcard program is used by some devices to expose internal storage through FUSE.

Conclusion: You took a complete wrong approach to and here. If you really wanted to deal with that on the file system level, you should have used a tool like tar (which is available and usually pre-installed on Android devices) to archive the contents while preserving permissions (the resulting "tarball" can then be copied to SD card, and the contents still be extracted to their original location properly). OTOH, as our backup tag-wiki will tell you, this is exactly what backup or apps like Helium - App Sync and Backup and Titanium Backup are for.

1: on older Android versions this often was YAFFS, on newer it's Extfs
2: usually FAT
3: or rather "reset" to the defaults used for content stored on the SD card
4: a normal user cannot do such stuff, as /data/data/<package_name> is not accessible to anyone but its owner and root

Community
  • 1
Izzy
  • 91,166
  • 73
  • 343
  • 943