Dateien mit Namen mit Unicode-Zeichen werden auf der SD-Karte beschädigt

Beim Mounten meiner SD-Karte auf meinem Galaxy SIII werden Dateien und Ordner auf der Karte mit Zeichen beschädigt, die nicht im ASCII-Bereich liegen. Dies geschieht, indem Sie einfach in den Speichereinstellungen „Karte aushängen“ auswählen und wieder einhängen. Es ist nicht erforderlich, die Karte physisch zu entfernen und wieder einzusetzen. Das Aus- und Wiedereinschalten des Telefons führt ebenfalls zu Beschädigungen.

Ordner, die mit einem Dateimanager auf dem Telefon angezeigt werden, werden als Dateien der Größe 0 mit einem Datum vom 31. Dezember 1969 (der Linux-Epoche) angezeigt und können nicht aufgerufen werden, um ihren Inhalt anzuzeigen. Sie werden als leere Ordner angezeigt. Dateien werden mit demselben Datum auf die Größe Null zurückgesetzt und können weder geöffnet noch in der Galerie, im Musikplayer usw. angezeigt werden. Sie werden als leerer Ordner geöffnet. (Siehe Bild unten)

Ich verwende die Standard-Android-Version 4.1.2.

Die Karte ist eine SanDisk 64 GB Micro-SDXC-Karte (Klasse 10). Das Problem trat auf, als die Karte werkseitig formatiert wurde (mit exFAT) und auch nach der Formatierung mit dem Telefon (Einstellungen > Speicher).

Beispiele für Dateinamen, die Ordnerbeschädigungen verursachen, sind „Aṣa“ oder „דניאל“. Es spielt keine Rolle, ob die Datei per USB-Übertragung oder durch Herausnehmen der Karte und Verwendung eines Lesegeräts auf einem Windows-PC auf die Karte kopiert wurde oder ob der Name (über das Telefon) geändert wurde, nachdem sich die Datei auf der Karte befand.

Dateien mit denselben Namen werden nicht beschädigt, wenn sie sich im internen Telefonspeicher befinden, und ich kann sie problemlos verwenden.

Beim Herausnehmen der Karte und Nutzung an einem PC mit Windows 7 sind Dateien zu sehen. Aber manchmal erscheinen die betroffenen Ordner doppelt. Das heißt, zweimal mit demselben Namen beide. Die Überprüfung der Festplatte mit Windows meldet Fehler und versucht, sie zu beheben. Aber wenn Sie die Karte wieder in das Telefon stecken, sind die Dateien wieder beschädigt.

Wie kann ich diese Beschädigung verhindern?

So zeigt der Dateimanager die beschädigte Datei oder Ordner an

Update: Bei einer mit FAT32 formatierten 2GB-Karte wurden Dateien nicht beschädigt. Aber nachdem ich es in exFAT formatiert hatte, konnte ich die Dateibeschädigung reproduzieren. Ich denke, ich kann eine schlechte SD-Karte ausschließen.

Weitere Informationen, dies ist ein Bericht von Windows 7 nach dem Ausführen von checkdisk. Beachten Sie, dass die 3 Dateien im Verzeichnis TestFolder vorhanden waren, das beschädigt war:

[Window Title]
Checking Disk Removable Disk (M:)

[Main Instruction]
Some problems were found and fixed

[Content]
Any files that were affected by these problems were moved to a folder named "Found" on the device or disk. Your device or disk is now ready to use.

If you removed the device or disk before all files were fully written to it, parts of some files might still be missing. If so, go back to the source and recopy those files to your device or disk.

[^] Hide details  [Close]

[Expanded Information]
Volume Serial Number is 6518-E54A
Windows is verifying files and folders...
Corruption was found while examining files in directory \TestFolder\ (0).
Corruption was found while examining files in directory \TestFolder\ (3).
Corruption was found while examining files in directory \TestFolder\ (6).
Corruption was found while examining files and directories.
File and folder verification is complete.
Windows has made corrections to the file system.

  62363648 KB total disk space.
  41656576 KB in 43 files.
       768 KB in 6 indexes.
       256 KB in use by the system.
  20706048 KB available on disk.

    131072 bytes in each allocation unit.
    487216 total allocation units on disk.
    161766 allocation units available on disk.

Ordner werden nicht beschädigt, wenn sie auf dem Telefon mit hebräischen Namen erstellt, dann ausgehängt und unter Windows überprüft werden. Erst nach erneuter Montage am Telefon.

MEHR DATEN: Dies sind meiner Meinung nach relevante Informationen von adb logcat:

I//system/bin/fsck.exfat( 1897): fsck.exfat 1.1.0p2

I//system/bin/fsck.exfat( 1897): [fsck] Invalid dir entry: (92675,0)
I//system/bin/fsck.exfat( 1897): [fsck] Wrong dir entry name hash
I//system/bin/fsck.exfat( 1897): [fsck] Successfully recovered

I//system/bin/fsck.exfat( 1897): Filesystem was modified.
I/logwrapper( 1897): /system/bin/fsck.exfat terminated by exit(4)

W/Vold    ( 1897): exfat -> Filesystem modified - rechecking (pass 2)
E/Vold    ( 1897): MDM :: sdCardWriteAccessBlocked 0
D/Vold    ( 1897): Detected exFAT file system.

Und beim Booten ohne problematische Dateinamen bekomme ich stattdessen ein nettes kleines

I//system/bin/fsck.exfat( 1897): No errors
I/Vold    ( 1897): exfat -> Filesystem check completed OK 

Und von adb shellkann ich versuchen, die Störenfriede zu sehen (nach dem erneuten Einhängen notieren Sie 2 Verzeichnisse mit anscheinend demselben Namen, die in einer Windows-Konsole als 2 Zeichen pro Unicode-Zeichen ausgegeben zu werden scheinen):

shell@android:/storage/extSdCard/Test $ ls * -l
ls * -l
drwxrwxr-x system   media_rw          2013-02-18 18:39 אבג
אבג: No such file or directory
1|shell@android:/storage/extSdCard/Test $
Auf den ersten Blick würde ich sagen, dass dies mit inkompatiblen Zeichensätzen zu tun hat (UTF8 auf der Android-Seite und welcher Windows-spezifische Zeichensatz auf dem PC) - aber Dateinamen sehen auf Ihrem Screenshot richtig geschrieben aus ... Nicht-ASCII Zeichen in Dateinamen scheinen in einigen Fällen große Probleme zu bereiten (dies ist nicht das erste Mal, dass ich diese Woche sehe ), weshalb ich versuche, sie so weit wie möglich zu vermeiden. Glücklicherweise verwenden meine Ethnix-Alben alle striktes ASCII 7bit in den Dateinamen :)
@izzy Eine Sache, mit der ich die Frage aktualisieren muss, ist, dass die Probleme auftreten, selbst wenn die Karte nie unter Windows verwendet wird. Dateien, die auf dem Telefon erstellt und dann in Hebräisch umbenannt werden, werden beim nächsten Einhängen der Karte beschädigt. Dateien im internen Speicher sind in Ordnung.
Das ist in der Tat eine wichtige Tatsache! Es betrifft also nur die externe SD-Karte - die interne " SD-Karte" (die SGS3 hat eine solche?) hat keine solchen Probleme, und auch keinen "Telefonspeicher" (wenn Sie dies testen können)? In diesem Fall sieht es nach einem Fehler mit entweder mountoder fsckin Kombination mit [ex]FAT aus. Die Frage ist: Geschieht dies beim Mounten oder beim Unmounten (dh nach dem Unmounten, Herausnehmen der Karte und Verwenden eines Kartenlesers auf Ihrem PC, sind sie bereits verschlüsselt)?
@Izzy Ich habe diese Informationen hinzugefügt. Korruption passiert beim Mounten, nicht beim Unmounten.
In StickMount (einer App zum Mounten von Flash-Laufwerken) gibt es eine Option mit der Aufschrift „UTF8 IO verwenden, wenn vom Kernel unterstützt“. Wird das ein Hinweis sein?
@Narayanan, das könnte in der Tat ein Hinweis sein. Ich bin mir nicht sicher, aber ich kann mir vorstellen, dass der Mount-Prozess versucht, etwas automatisch zu erkennen, fehlschlägt (und hier etwas kaputt geht), aber schließlich korrekt montiert wird (wenn es bereits kaputt ist). Wenn man also den ersten Schritt überspringen könnte (und ihn von Anfang an korrekt montieren lässt), könnte das das Problem lösen. frozenkoi: Wenn du die Möglichkeit hast, ein logcat/ dmesgaus dem Startvorgang zu bekommen (zB per adb logcatsofort nach dem Booten, wenn die relevanten Einträge noch zwischengespeichert sind), würde das helfen!
@izzy Hinzugefügt die Informationen über lolcat. Das vollständige Protokoll zu setzen, schien übertrieben. Und das fängt an, eher wie ein Fehlerbericht auszusehen. Ich konnte nicht finden, wo ich diese Informationen an Samsung senden kann.
Du meinst logcat, nicht Lolcat :) Und aus deinen Einträgen sehe ich, dass ich mit meiner ersten Vermutung richtig lag (inkompatible Zeichen). Wie kam es zu dem Eintrag, aus dem Sie lsam Ende Ihrer Frage zitiert haben? Das sieht aus wie einer der Störenfriede. Wie sollte/sollte dieser Name ursprünglich lauten? PS: Es sind nicht "zwei Verzeichnisse mit demselben Namen", das erste ist "normale" Ausgabe von ls, das zweite wiederholt es in einer Fehlermeldung. Sieht so aus, als ob dieses Goyishe-Android Hebräisch nicht wirklich mag ...
@Izzy (a) Ich meinte absolut lolcat(b) Ich habe mit dem Dateimanager, der mit dem SIII geliefert wird, einen Ordner erstellt und ihn אבג genannt. Habe dann das Handy neu gestartet.
LOL wirklich lolcat -- süß ... Ja, wenn es sich um einen Fehlerbericht handelt, ist dies möglicherweise der falsche Ort. Wenn Sie eine Lösung/Fix gefunden haben, vergessen Sie bitte nicht, uns dies mitzuteilen! Viel Glück und חג פסח כשר
Gepostet auf der Entwicklerseite von Samsung: developer.samsung.com/forum/board/thread/…

Antworten (4)

Ich habe mein S3 vor ein paar Tagen von Android 4.1.2 (Stock Samsung ROM) auf 4.3 aktualisiert. Das Problem trat bei mir seit anderthalb Jahren immer wieder auf, genau wie oben beschrieben, in zwei 4.0.x (ICS) Versionen sowie in Jelly Bean 4.1, aber in 4.3 scheint es endlich behoben zu sein: Nach dem Update habe ich kopierte viele Dateien mit hebräischen Unicode-Namen auf meine microSD-Karte, und sie haben zahlreiche Unmount/Remounts der Karte und Neustarts des Telefons ohne Probleme überstanden.

Übrigens war ein weiteres Problem, auf das ich gestoßen war, dass automatische erneute Scans der Medienordner auf der Karte (durchgeführt von der System-App „Media Storage“ von Android), die jedes Mal auftreten, wenn eine Karte eingelegt oder das Telefon vom USB getrennt wird, a sehr lange Zeit (manchmal Stunden). Dies führte wiederum zu Problemen bei der Synchronisierung meiner großen Musikbibliothek zwischen meinem Mac und meinem Telefon mit dem iSyncr-Dienstprogramm. Dieses Problem ist auch vollständig verschwunden, und ich vermute, dass der Android-Medienscanner nicht gut mit den beschädigten Dateien umgegangen ist.

Zusätzliche Details: Telefon: GT-I9300 Internationale Version, nicht gerootet, mit der offiziellen israelischen Samsung-Firmware ohne Markenzeichen. Karte: SanDisk 64 GB Klasse 10 (wie die IIUC des ursprünglichen Fragestellers), auf einem Mac in exFAT formatiert. Ich habe mich nach dem 4.3-Upgrade nicht einmal um eine Neuformatierung gekümmert – ich habe die Karte einfach auf dem Mac gemountet, um alle vorhandenen beschädigten Dateien der Länge 0 zu löschen, die, wie bereits erwähnt, nicht von den verschiedenen Android-Dateidienstprogrammen gelöscht werden können.

Gut zu hören. Ich warte immer noch darauf, dass das Update für meinen Mobilfunkanbieter verfügbar ist.
Das Update wurde vor ein paar Tagen für den Netzbetreiber verfügbar gemacht, an den mein Telefon versklavt, ich meine, gebunden ist. Konnte meine Dateien bisher behalten.

Ich habe dasselbe mit meiner 32-GB-Sandisk-Micro-SD-Karte der Klasse 10 im Galaxy Tab 2 erlebt. Die SD-Karte ist echt, also weiß ich, dass das nicht das Problem ist.

Ich habe jedoch festgestellt, dass dies für mich funktioniert.

  1. Formatieren Sie die Karte auf Ihrem PC oder Mac im NTFS-Dateisystem.
  2. Laden Sie die Paragon NTFS / HFS apk-App für Ihr Android-Gerät herunter
  3. Ohne JEDE NTFS-App für den Android erkennt der Android das eingelegte SD-Kartenformat NICHT, da der Android nur das FAT-Dateisystem erkennt
  4. Legen Sie die Micro-SD-Karte in das Gerät ein und starten Sie das Gerät neu (wenn das Kartensymbol in der Benachrichtigungsleiste unten rechts angezeigt wird, ignorieren Sie)
  5. Gehen Sie auf Android Paragon NTFS / HFS-Tool apk und öffnen Sie es und überprüfen Sie die Festplatte / das Format mit der Android-App
  6. Starten Sie das Gerät erneut, mit eingelegter SD-Karte, lassen Sie die Karte eingelegt und verbinden Sie das Android-Gerät mit dem PC, die externe Festplatte sollte jetzt verfügbar sein und in NTFS formatiert sein

Die Karte sollte über die Paragon NTFS-App automatisch aktiviert werden, wenn das Gerät eingeschaltet wird.

Ich habe alle möglichen Methoden ausprobiert, um die SD-Karte im FAT 32 zu haben, aber es hält einfach nicht, Ordnernamen ändern sich, Dateien verschwinden.

Laut der Samsung- Seite war es ein Fehler, der jetzt behoben ist und mit dem nächsten Firmware-Update (wann immer das sein mag) veröffentlicht werden soll.

Sie haben keine andere Lösung, als eine andere zu kaufen. Gern geschehen. ;)