Replacing files with copies of themselves causing Android application to crash

by harry songhurst   Last Updated April 14, 2018 10:11 AM

I'm working with the Twitter Android application in an x86, Android 7.0, emulated environment, attempting to handle login sessions by cloning and restoring the application's data on disk.

For some reason, when tarring /data/data/com.twitter.android/databases, then immediately extracting that tarball back to the same place (so as to overwrite the files with copies of themselves), the application becomes bricked, crashing on startup until I do a full reinstall of the app. The same is true if I simply cp -rp the directory elsewhere, remove it, then restore it from the copy with cp -rp again.

This can be replicated by installing the Twitter application, logging in manually, then running the following from /data/data/com.twitter.android/ in an adb shell with escalated privileges (adb root):

generic_x86:/data/data/com.twitter.android # (ls -la databases; tar -cf /sdcard/db.tar databases; tar -xpf /sdcard/db.tar; ls -la databases)

ls -la before tar:
total 3200
drwxrwx--x 2 u0_a98 u0_a98   4096 2018-04-13 21:52 .
drwx------ 9 u0_a98 u0_a98   4096 2018-04-13 21:51 ..
-rw-rw---- 1 u0_a98 u0_a98 512000 2018-04-13 21:52 0-49.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 0-49.db-journal
-rw-rw---- 1 u0_a98 u0_a98  28672 2018-04-13 21:52 0-lru_key_value.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 0-lru_key_value.db-journal
-rw-rw---- 1 u0_a98 u0_a98  16384 2018-04-13 21:52 0-scribe.db
-rw------- 1 u0_a98 u0_a98  16928 2018-04-13 21:52 0-scribe.db-journal
-rw-rw---- 1 u0_a98 u0_a98 638976 2018-04-13 21:52 984053504628150273-49.db
-rw------- 1 u0_a98 u0_a98  74384 2018-04-13 21:52 984053504628150273-49.db-journal
-rw-rw---- 1 u0_a98 u0_a98  20480 2018-04-13 21:52 984053504628150273-dm.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 984053504628150273-dm.db-journal
-rw-rw---- 1 u0_a98 u0_a98  20480 2018-04-13 21:52 984053504628150273-drafts.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 984053504628150273-drafts.db-journal
-rw-rw---- 1 u0_a98 u0_a98  28672 2018-04-13 21:52 984053504628150273-lru_key_value.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 984053504628150273-lru_key_value.db-journal
-rw-rw---- 1 u0_a98 u0_a98  40960 2018-04-13 21:52 984053504628150273-scribe.db
-rw------- 1 u0_a98 u0_a98  12824 2018-04-13 21:52 984053504628150273-scribe.db-journal
-rw-rw---- 1 u0_a98 u0_a98  16384 2018-04-13 21:52 evernote_jobs.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 evernote_jobs.db-journal
-rw-rw---- 1 u0_a98 u0_a98  36864 2018-04-13 21:52 global.db
-rw------- 1 u0_a98 u0_a98  12824 2018-04-13 21:52 global.db-journal
-rw-rw---- 1 u0_a98 u0_a98  16384 2018-04-13 21:52 google_app_measurement_local.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 google_app_measurement_local.db-journal
-rw-rw---- 1 u0_a98 u0_a98  16384 2018-04-13 21:51 persistent_jobs.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:51 persistent_jobs.db-journal

ls -la after tar extraction:

total 3184
drwxrwx--x 2 u0_a98 u0_a98   4096 2018-04-13 21:52 .
drwx------ 9 u0_a98 u0_a98   4096 2018-04-13 21:51 ..
-rw-rw---- 1 u0_a98 u0_a98 512000 2018-04-13 21:52 0-49.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 0-49.db-journal
-rw-rw---- 1 u0_a98 u0_a98  28672 2018-04-13 21:52 0-lru_key_value.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 0-lru_key_value.db-journal
-rw-rw---- 1 u0_a98 u0_a98  16384 2018-04-13 21:52 0-scribe.db
-rw------- 1 u0_a98 u0_a98  16928 2018-04-13 21:52 0-scribe.db-journal
-rw-rw---- 1 u0_a98 u0_a98 638976 2018-04-13 21:52 984053504628150273-49.db
-rw------- 1 u0_a98 u0_a98  74384 2018-04-13 21:52 984053504628150273-49.db-journal
-rw-rw---- 1 u0_a98 u0_a98  20480 2018-04-13 21:52 984053504628150273-dm.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 984053504628150273-dm.db-journal
-rw-rw---- 1 u0_a98 u0_a98  20480 2018-04-13 21:52 984053504628150273-drafts.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 984053504628150273-drafts.db-journal
-rw-rw---- 1 u0_a98 u0_a98  28672 2018-04-13 21:52 984053504628150273-lru_key_value.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 984053504628150273-lru_key_value.db-journal
-rw-rw---- 1 u0_a98 u0_a98  40960 2018-04-13 21:52 984053504628150273-scribe.db
-rw------- 1 u0_a98 u0_a98  12824 2018-04-13 21:52 984053504628150273-scribe.db-journal
-rw-rw---- 1 u0_a98 u0_a98  16384 2018-04-13 21:52 evernote_jobs.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 evernote_jobs.db-journal
-rw-rw---- 1 u0_a98 u0_a98  36864 2018-04-13 21:52 global.db
-rw------- 1 u0_a98 u0_a98  12824 2018-04-13 21:52 global.db-journal
-rw-rw---- 1 u0_a98 u0_a98  16384 2018-04-13 21:52 google_app_measurement_local.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:52 google_app_measurement_local.db-journal
-rw-rw---- 1 u0_a98 u0_a98  16384 2018-04-13 21:51 persistent_jobs.db
-rw------- 1 u0_a98 u0_a98   8720 2018-04-13 21:51 persistent_jobs.db-journal

As you can see, the output of the two ls executions are nearly identical, all permissions are preserved, however the size of the directory after tar creation and subsequent extraction is smaller than before, I figure this is just the OS optimising the number of disk blocks used though?

I have searched the whole filesystem for soft links to the directory in question and have come up with nothing. You can also see from the output of ls -la that the directory only has 2 hard links (one from .../databases/ and one from it's own '.' entry), so I'm pretty sure no links are being destroyed.

I'm doing all of this when the application is not running, and I've tried restarting the system inbetween replacing the files with copies of themselves and starting the application. I've also tried on Android 8.0, and 7.1.1 with the results.

I'm very confused as to what's causing this haha, any help/ideas are greatly appreciated.

Tags : applications


Related Questions




Image and Video Files not showing up in Gallery

Updated April 08, 2015 18:04 PM