adb pull /data

Hallo zusammen,

könnte es sein, dass /data unterschiedlich abgelegt ist...

CM11: /data (pull OK)
AOSP: /data (pull failed)
AOSP: /data/data (pull failed)
AOSP: /storage/sdcard0/Android/data (pull OK)

oder liege ich falsch?

/data ist /data! Wird wohl an den Rechten der adb liegen.

Ja, kommt mir langsam auch so vor Und wo/wie kann ich dies beinflussen?

Ich bekomme /system herunter, nur /data nicht.


Auch fällt mir auf, in der letzten ROM funktionierte ein einfacher Nun muss ich mit
herantreten, wenn ich herumwurschteln möchte.

Funktioniert ja so sowieso nicht, da es eine aktiv genutzte Partition ist.
Solltest das System vorher stoppen und später wieder starten.
Zudem würde ich es per TAR auf die SD-Karte packen (denn dann bleiben die rechte erhalten)

Normalerweise soll man ja auch nicht einfach via adb alle Daten abziehen können (Datenschutz/Sicherheit) ...

CM11 und AOSP sind nicht verantwortlich für das unterschiedliche Verhalten, sondern der ROM-Entwickler, der dieses Verhaten in "seiner" ROM so einstellt. - Manche ROMs geben *sofort* eine root-shell, bei anderen muss man das erst aktivieren bzw. mit "su" arbeiten.

Auch gibt es unterschiedliche Arten von ROM-Builds: eng (alles offen - keine Restriktionen), userdebug (Großteil offen) und user (nichts offen). - Das kann man i. d. R. (als Teilstring) in der Build-Nummer der ROM in "Über das Telefon" ablesen oder in einer build.prop-Datei finden.

Es kommt also darauf an, ob die ROM (bzw. der Developer) dir den Zugriff auf die data-Partion via adb gibt (Phone bzw. ROM gerootet, Developer Options/USB Debugging enabled, "Root in the shell" ROM-seitig aktiviert, data-Partition bereits rw gemounted in der adb shell ...).

Und wie @N2k1 bereits schrieb, ist die sicherste Methode, um Daten *konsistent* von einem Phone zu holen, über z. B. eine shell via (Custom) Recovery (tar/dd), da hierbei die data-Partition nicht vom System benutzt wird.

Wenn mratix das System rw mounten kann, dann muß der Root-Zugriff wohl aktiviert sein.
Weiterhin wird /data immer rw gemountet, da das System ja sonst keine Daten abspeichern kann.
Der Zugriff für Root auf /data kann durch keine Option eingeschränkt sein (die Optionen eng/userdebug/user sollten nur das Verhalten des Systems - nicht aber den Lese-Zugriff beeinflussen)
Ein dd ist in der Tat nur im Recovery sinnvoll, ein TAR hingegen geht auch im laufenden System

adb shell
stop
tar cz /sdcard/data.tar /data
start
exit
adb pull /sdcard/data.tar
adb rm /sdcard/data.tar

Schon klar. Man kommt aber mit einem eigenen Session-Kontext und evtl. einem anderen User (z. B. User "shell") via adb auf die Partition. Das ist nicht notwendigerweise identisch mit dem Verhalten der data-Partition für das System selbst. Die Detaillierung soll @mratix (und anderen) ein paar Ideen geben, vor allem, dass ROMs sich bzgl. des Themas nicht immer gleich verhalten. - Er hat ja sonst alles "im Griff" ...

Danke euch für die inhaltlich guten Beiträge. Werde sie nachher gründlich durchkauen.

Es hat sich herausgestellt, dass die aktualisierte AOSP ROM 4.4.2 inhaltlich noch eine 4.0.x war. Einige Sachen waren merkwürdig und auffällig. Auch das Verhalten von ADB.

Normalerweise ziehe ich Backups für Apps+Daten mit Titanium. Komplette auf CWM/TWRP-Ebene.

Dort hat es erstmal Probleme gegeben. CWM hat nach exakt 4.0GB ein Abbruch gemeldet

Habe nun zurückgeflashed, sieht vorerst gut aus.

Mit 'adb sync' komme ich nicht ganz klar. Es fungiert nur in eine Richtung.

mratix schrieb:

Dort hat es erstmal Probleme gegeben. CWM hat nach exakt 4.0GB ein Abbruch gemeldet

Zum Vergrößern anklicken....

Das klingt nach einem falschen oder falsch eingestelltem CWM.
4GB ist ja die FAT-Grenze.. aber CWM sollte die Sachen dann "zerlegen".

Ne, habe nichts am Recovery verändert. ...würde aber schrecklich gerne
Der CWM schmeckt mir irgendwie gar nicht

Darf ich euch die betroffene log, zum kurzen drübergucken, geben?
U.a. stehen auch Details der Übeltäter ROM drinnen.

Klingt nach einem MTK-Device?! (Ich lese da etwas von rua1 - was für mich nach MTK DT klingt)
Welches Gerät ist es denn? Vielleicht sollten wir dorthin umziehen, da das Erstellen eines (passenden) Recovery-Image vom Gerät abhängt.

Autsch! Da brennt ja eine ganz andere Glühbirne: rua1 autoCWM 5.5.0.4

Es ist ein Honor 3C, H30-U10 mit MT6582.
Gerooted nach XDA-Anleitung (#1-5) und des Dalet11-Threads. CWM stammt(e) auch aus dem XDA-Pakethttp://forum.xda-developers.com/showpost.php?p=54603787&postcount=6 (am Ende von #6).

Mittlerweile hab ich so um die 15 ROM's geflashed.
Und die letzte 4.4.2_AOSP_ROM_Honor-3c_h30u-10_MGeeky war etwas faul. Ziemlich faul
Da ist ein 4.0.4 drinnen, und anscheinend auch o.g CWM-Ersatz

OK, ich möchte das Thema adb, nach der Erkenntnis, nicht weiter zumüllen.
Ein Neuflashen des Recovery wird sicherlich einiges lösen.

Nochmals Vielen Dank an Alle, besonders an N2k1

Nach dem angehängten Recovery Log gibt es ja bereits bei den Partitionen Probleme mit der Zuordnung / dem Mounten (fstab, init.rc et al.). - Die referenzierten Dateien (xda) sind meines Wissens alle okay und einsetzbar. - Aber diese mgeeky-ROM ist vermutlich total verbuggt (eng-Build, Referenzierung auf Android-Emulator, falsche SD Card-Lokation ...). - Egal, ein adb-Problem ist es jedenfalls nicht gewesen ... Gute Nacht!