Hallo, ich habe auf einem Android-Tablet seit kurzem ein seltsames Problem: Ich habe schon lange eine 128GB Micro-SD Karte dauerhaft im Tablet. Die Karte lässt sich normal lesen und scheinbar auch normal beschreiben, Dateien und Verzeichnisse löschen etc. Vor kurzem ist mir aber aufgefallen, dass Audio-Aufnahmen, die ich auf dem Tablet gemacht habe und die ohne Fehlermeldung auf die Karte geschrieben wurden, später verschwunden waren. Und wenn ich jetzt Dateien auf die Karte schreibe oder zB ein Verzeichnis lösche, dann funktioniert das ohne Fehlermeldung. Wenn ich die Karte dann aber auswerfe und wieder einlege, sind alle diese Operationen quasi wieder rückgängig gemacht. Seltsamer Weise lassen sich die auf die Karte geschriebenen Daten vor dem Auswerfen normal lesen. Ich kann sogar zB ein zip File auf der Karte öffnen und dorthin entpacken und die entpackten Dateien lesen. Nach dem Auswerfen und neu einlegen ist aber alles wieder verschwunden. Es scheint so, als hätte die Karte einen Schreibschutz, was aber nicht der Fall ist und ich kann ja zunächst schreiben. Nur ist das irgendwie "flüchtig". Was kann das sein?
Horst M. schrieb: > Es scheint so, als hätte die Karte einen Schreibschutz, was aber nicht > der Fall ist sicher? Denn verschlissene Flash Speicher verhalten sich oft genau so. Du merkst es wegen dem Cache verzögert.
:
Bearbeitet durch User
Ich habe eine SanDisk (blumiger Name) SD-Karte, die sich genauso verhält. Besonders viel wurde sie übrigens nicht genutzt, bevor sie dieses Verhalten entwickelte. Jetzt kann man die Karte, egal womit, auch nicht löschen, formatieren, zurücksetzen.
Ich habe jedenfalls keinen Schreibschutz gesetzt. Wenn da einer wäre, müsste es doch bei einem Schreibversuch eine Fehlermeldung geben? Heißt das, dass der Cache einem vorgaukelt, dass eine Operation abgeschlossen wurde, dass aber in Wirklichkeit gar nicht auf die Karte geschrieben wird? Womit kann ich die Karte testen, ob sie wie Du sagst verschlissen ist? Sie ist vielleicht fünf Jahre alt und ich würde sagen, dass ich sie nur wenig beschrieben, sondern in allererster Linie nur gelesen habe. Sie ist und war noch nie voll.
Horst M. schrieb: > Womit kann ich die Karte testen, ob sie wie Du sagst verschlissen ist? Geht halt nur mit komplettem Datenverlust. Mit dem offiziellen "SD Card Formatter" mit einem Kartenleser an einem PC formatieren, und wenn das durchlaufen sollte, mit h2testw (c't) prüfen.
Harald K. schrieb: > Ich habe eine SanDisk (blumiger Name) SD-Karte, die sich genauso > verhält. > > Besonders viel wurde sie übrigens nicht genutzt, bevor sie dieses > Verhalten entwickelte. > > Jetzt kann man die Karte, egal womit, auch nicht löschen, formatieren, > zurücksetzen. Interessant - bei mir ist es auch eine SanDisk-Karte.
Wahrscheinlich schreibt der Rechner dir Daten noch gesund in den Cache und unterwegs zum SD-Speicher liegt der Fehler? Sofort alle Daten sichern, es kann noch schlimmer werden. In günstigen Fällen hilft Dir eine neue SD, die vorher mit h2testw getestet wurde. In ungünstigen Fällen hast Du einen SW-Fehler oder es wütet ein Virus, der noch nicht erkannt wurde?
Ich hatte ein solches Verhalten mal bei einer gefälschten MicroSD-Karte. Gelabelt war die mit Samsung, damals 128 GB glaube ich. Bis 32 GB war alles normal und was danach drauf geschrieben wurde war dann eigentlich weg. Scheinbar war der tatsächliche Speicherplatz kleiner als das Label und die Meldung an das Betriebssystem. Während des Schreibens gab es aber keine Fehlermeldungen. Die Fälschung wurde damals durch den Samsung-Support herausgefunden, der gute Fotos bat. Auf der Karte war irgendein Merkmal (Symbol oder sowas, ich weiß es nicht mehr genau) anders als bei den Originalen. Bestellt wurde bei Amazon. Aufgrund Lagerbestand hat Amazon dann einen anderen Anbieter vorgeschlagen. Von dem stammte dann die gefälsche Karte. Die Ersatzlieferung kam damals völlig unproblematisch von Amazon.
Horst M. schrieb: > Es scheint so, als hätte die Karte einen Schreibschutz, was aber nicht > der Fall ist und ich kann ja zunächst schreiben. Nur ist das irgendwie > "flüchtig". Was kann das sein? Eigentlich ist das genau das Verhalten, welches eine verschlissene aber noch nicht defekte Speicherkarte zeigt. Der Flashcontroller schaltet auf read-only, um Datenverlust zu vermeiden. Deine vorhandenen Daten sind weiter lesbar. Was Dich jetzt reinlegt ist Android mit seinem Schreibcache. So klappt die Dateioperation anscheinend erstmal und schlägt erst beim Sync des Dateisystems fehl. Der wird Dir aber nicht oder nicht eindeutig erkennbar gemeldet. Hol Dir eine neue Karte, kopier alles rüber und schau ob es dann funktioniert. Oder am besten zwei, eine als Backup.
Es koennte auch daran liegen das ein altes Androidprogram mit nicht vorhandenen Rechten an Stellen im Dateisystem schreibt wo es das nicht mehr darf. Das fuehrt manchmal auch zu schraegem verhalten. Vanye
Horst M. schrieb: > Heißt das, dass der Cache einem vorgaukelt, dass eine Operation > abgeschlossen wurde, dass aber in Wirklichkeit gar nicht auf die Karte > geschrieben wird? So ist es. Das Programm schreibt in den Cache. Die Persistierung ins Speichermedium findet später durch den Linux Kern statt. Davon bekommt das Anwendungsprogramm nichts mit. Das ist wie beim Drucken. Die Textverarbeitung liefert das Dokument beim Druckertreiber ab. Sie wird nicht erfahren, ob der Papiertransport klemmt.
Also ich kann mir keinen Planeten vorstellen, auf dem ein nicht fehlerfrei weg-schreibbarer (dirty-)cache nicht zu einem oder mehreren lautstarken oder zumindest gut sichtbaren Fehlern des Betrübssystems führen würde.
Ich werfe hier mal Stichworte wie Mount namespaces und Mandatory Access Control (MAC) in den Raum. Ich hab schon ganze Partitionen formatiert und neue Dateien geschrieben. Dass die Operationen alle fehlschlagen bekommt das Terminal nicht mit, man sieht lediglich avc: denied in logcat.
Alexander schrieb: > Ich hab schon ganze Partitionen formatiert > und neue Dateien geschrieben. Dass die Operationen alle fehlschlagen > bekommt das Terminal nicht mit, Das wage ich mal sehr stark zu bezweifeln. Ansonsten könntest du ja bestimmt ein Szenario beschrieben, in welchem man ohne Fehlermeldung so etwas bewerkstelligen könnte.
Ihr könnt hier gerne detailliert aus diskutieren wie diverse Linzx Programme Fehler erkennen und melden. Beim TO geht es jedoch um Android!
Norbert schrieb: > Worauf setzt das nochmal auf? Der Kernel zeigt dem User gar nichts an. Es kommt auf die Software drumherum an, die bei Android anders.
Es geht hier um scheinbar erfolgreiche Schreibzugriffe ohne Fehlermeldung. Schreibt eine App Dateien in ihren eigenen Mount namespace, so sind die Dateien für andere Apps unsichtbar. Es scheint als wären die gelöscht. Ähnlich verhält es sich mit klassischen Coreutils (wie cp, dd, rm) wenn man Operation ausführt die durch die SELinux-Policy verboten sind. Alles stimmig, aber nur bis man die root-shell wieder verlässt. Aber ist schon ein paar Jahre her und vermutlich irrelevant. Ich denke hier ist eine tote Speicherkarte der Grund.
Auch unter Android landen die Daten nicht zwangsläufig sofort auf dem Datenträger. Nicht umsonst gibt es die Funktion den Datenträger sicher zu entfernen. Erst danach kann man sicher sein, dass die Daten auch wirklich geschrieben wurden.
Horst M. schrieb: > Ich habe schon **lange** eine 128GB Micro-SD Karte **dauerhaft** im Tablet. Meine Erfahrung: die Karte ist einfach nur kaputt. Bei "windigen" Consumerexemplaren wie z.B. Intenso oder Hama kann das schon nach kurzer Zeit passieren. > Ich kann sogar zB ein zip File auf der Karte öffnen und dorthin > entpacken und die entpackten Dateien lesen. Die Daten landen wahrscheinlich nur im RAM-Cache der Speicherkarte. Wie groß ist das Zip-File? Norbert schrieb: > Also ich kann mir keinen Planeten vorstellen, auf dem ein nicht > fehlerfrei weg-schreibbarer (dirty-)cache nicht zu einem oder mehreren > lautstarken oder zumindest gut sichtbaren Fehlern des Betrübssystems > führen würde. Selbst wenn die Daten auf der SD-Karte sind, sind sie dort noch lange nicht auf dem Flash. Und wenn das Schreiben dort letztlich schiefgeht, dann merkt das OS überhaupt nichts davon, weil für das OS der Schreibvorgagn schon lange abgeschlossen ist. Es gibt angesichts des CRA sogar explizit solche USB und (micro)SD Speichermedien, wo das Schreiben vom Speichermedium ordentlich quittiert wird (der Virus darf sich ruhig freuen), aber auf dem Flash einfach nichts verändert wird.
Lothar M. schrieb: > Selbst wenn die Daten auf der SD-Karte sind, sind sie dort noch lange > nicht auf dem Flash. Besitzen SD-cards tatsächlich einen signifikanten RAM-Datencache? Habe noch nie etwas in dieser Richtung gehört, kann's aber auch nicht ausschließen.
Lothar M. schrieb: > Die Daten landen wahrscheinlich nur im RAM-Cache der Speicherkarte. Wie > groß ist das Zip-File? Ich glaube nicht an diesen Cache. Den hat eher das Android-Gerät, in dem die Karte steckt.
Norbert schrieb: > Besitzen SD-cards tatsächlich einen signifikanten RAM-Datencache? Nö, da halluziniert die Lothar-LLM.
Norbert schrieb: > Also ich kann mir keinen Planeten vorstellen, auf dem ein nicht > fehlerfrei weg-schreibbarer (dirty-)cache nicht zu einem oder mehreren > lautstarken oder zumindest gut sichtbaren Fehlern des Betrübssystems > führen würde. Genauso ist es aber. Ansonsten wäre des Konzept "Schreibcache" ja sinnfrei. Natürlich bekommt der Betriebssystem(-kern) das mit und wird das auch irgendwie melden. Zu dem Zeitpunkt kann die Applikation aber bereits längst geschlossen sein. Es gibt z.B. Situationen wo Dateien gar nie auf der Platte landen. Z.b. wenn man mit dem gcc compiliert. Der erzeugt während des Compilieren viele Zwischenergebnisse für die er temporäre Dateien erstellt und kurze Zeit später wieder löscht. Das wird alles im Schreibcache aufgefangen und kommt gar nicht erst bis zur Platte runter.
Andreas M. schrieb: > Natürlich bekommt der Betriebssystem(-kern) das mit Darum ging es mir. Die Info kommt auf jeden Fall, man kann sie nun ignorieren oder nich' Und da wir uns über ein Linux System "unten drunter" unterhalten, ich persönlich finde ja Systemaufrufe wie syncfs() recht charmant. Insbesondere da EBADF, EIO, ENOSPC, ENOSPC, EDQUOT zurück gemeldet werden. Man muss es aber auch wollen. (Das mit den sicher geschriebenen Daten)
Du hast aber kein Android-Gerät, oder? Da gibt's überhaupt keine Fehlermeldungen. Irgendwann fällt auf das die Karte Apps komisch werden lässt, und das isses. Nicht-technisch-versierte Anwender kommen da nichtmal drauf das irgendwas nicht stimmt. Aber irgendeine Meldung weder in einer App noch vom OS kommt nicht, wegen gar nix. Es mag sein das untendrin irgendwo ein Log oder so ist, aber da kommt keiner dran, zumindest nicht offiziell.
Jens M. schrieb: > Du hast aber kein Android-Gerät, oder? > Da gibt's überhaupt keine Fehlermeldungen. Das wäre dann eine ungehörige Android Schlampigkeit. Linux stellt doch alles zur Verfügung. Das darauf liegende JVM-Gelumpe, so wie auch das darüber liegende Java-App-Gelumpe sollte ja wohl in der Lage sein, passende Aufrufe zur Synchronisation aufzurufen und den Return Status zu prüfen. Im Fehlerfall würde ja schon ein unspezifiziertes System-Pop-Up ausreichen: ›Achtung: Schreibfehler auf der SD-Karte. Ihre Daten finden sie in der nächsten Klärgrube.‹ ausreichen. Vielleicht ein Details Button für die Neugierigen: ›Wir haben keine Ahnung was mit unserer Software passiert, es interessiert uns auch nicht wirklich, gut ist es aber nicht!‹
Norbert schrieb: > Das wäre dann eine ungehörige Android Schlampigkeit. Android Apps werden von Hinz und Kunz entwickelt, ich würde da nicht allzu viel erwarten.
Michael B. schrieb: > Doch, steht im ersten Satz des TO. Der Norbert aber nicht, der meinte das Android ja wohl Fehlermeldungen sollte. Was es nicht tut. Evtl. gibt's in irgendeinem Statusfenster eine Meldung, die aber nicht aufpoppt sondern gesucht werden muss, und selbst das bezweifle ich. Mir sind jedenfalls noch keine Hinweise aufgefallen, außer in bestimmten Apps z.B. zur Datenübertragung. Aber einfach so eine Meldung gibt es nicht.
Jens M. schrieb: > Aber einfach so eine Meldung gibt es nicht. Was sollte ein typischer Smartphonenutzer auch damit anfangen?
Harald K. schrieb: > Was sollte ein typischer Smartphonenutzer auch damit anfangen? Er könnte z.B. von jeder der Dateien eine MD5-Prüfzahl bilden und sie später vergleichen. Es sind ja nur gaaaaanz wenige ... :-) Interessanter scheint mir, dass z.B. manche Fotos ohne Wissen des Users irgendwo auf einer Cloud landen.
:
Bearbeitet durch User
Lu schrieb: > Er könnte z.B. von jeder der Dateien eine MD5-Prüfzahl bilden und sie > später vergleichen. Ich schrieb "typischer Smartphonenutzer". Das sind Leute, die beim U-Bahnfahren tiktok-glotzen, und die Whatsapp & Co. verwenden. Zwischendrin daddeln einige noch irgendwelche Onlinegames.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.