Hallo zusammen,
ich arbeite derzeit mit einem ARM7-System, auf dem ein Massenspeicher
läuft. Der Massenspeicher setzt auf Flash-Speicher auf, der Flash ist
mit FAT16 formatiert.
Ich kann via Windows problemlos Dateien auf dem Massenspeicher anlegen,
was aber nicht funktioniert, ist das Öffnen einer Datei, die über das
Dateisystem erzeugt wurde.
Erstelle ich eine Datei per Firmware und möchte sie dann über Windows
öffnen, dann kommt die Fehlermeldung "Datei kann nicht gefunden werden".
Wenn ich auf die Datei zeige, dann bekomme ich die richtige Größe und
Datumsinformationen angezeigt, im Eigenschaften-Dialog erscheint das
nicht.
Der Eintrag im Stammverzeichnis und in der FAT erscheint auf den ersten
Blick richtig, auch das Auslesen der Datei mit WinHex funktioniert
problemlos, nur mit Windows-Bordmitteln funktioniert es nicht.
Weiß jemand, wodurch dieses Fehlerbild verursacht werden kann?
Frank
Wie ist das Windows-System mit dem Flash-Speicher verbunden? Können da
etwa beide Seiten gleichzeitig darauf herumschreiben bzw. -lesen?
Das geht in die Hose, weil so ein Dateisystemtreiber nicht davon
ausgeht, daß quasi "hinter seinem Rücken" sich die Inhalte des
Dateisystems ändern können. Aus Geschwindigkeitsgründen werden bestimmte
Dateisysteminhalte im Cache gehalten, so z.B. die FAT und
Verzeichnisinhalte.
Der Massenspeicher greift über den selben Controller auf den
Flash-Speicher zu. Quasi-gleichzeitiger Zugriff ist zwar prinzipiell
möglich, aber das kann ich für den Moment definitiv ausschliessen, da
die Erstellung der Datei erfolgt, bevor ich in der Firmware die
USB-Verbindung zum PC herstelle und danach keine Zugriffe auf das
Dateisystem mehr erfolgen.
Frank Bär schrieb:> aber das kann ich für den Moment definitiv ausschliessen, da> die Erstellung der Datei erfolgt, bevor ich in der Firmware die> USB-Verbindung zum PC herstelle und danach keine Zugriffe auf das> Dateisystem mehr erfolgen.
Gut, wenn das so ist, dann liegt das Problem wohl doch in Deiner
Implementierung des Dateisystems.
Entweder Deine Berechnungen, welche Cluster zur Datei gehören, sind
inkorrekt (das ließe sich durch pc-seitiges Erzeugen einer Datei und
Überprüfen der Verzeichnis- und FAT-Einträge überprüfen), oder aber Du
hast irgendwas anderes wesentliches vergessen. Sind beide Kopien der FAT
identisch?
Was geschieht, wenn Du (in einem Konsolenfenster) chkdsk -r aufrufst?
Rufus Τ. Firefly schrieb:> Gut, wenn das so ist, dann liegt das Problem wohl doch in Deiner> Implementierung des Dateisystems.>> Entweder Deine Berechnungen, welche Cluster zur Datei gehören, sind> inkorrekt (das ließe sich durch pc-seitiges Erzeugen einer Datei und> Überprüfen der Verzeichnis- und FAT-Einträge überprüfen), oder aber Du
Darüber habe ich auch schon nachgedacht. Die Einträge des PC sehen nicht
derart anders aus. Testweise habe ich mit WinHex die Datei mal
ausgelesen und dann mit geändertem Namen auf den Massenspeicher kopiert.
Lediglich die Datumsangaben sind anders, öffnen kann ich die Datei
problemlos.
Ich habe so langsam den Eindruck, dass Windows noch an anderer Stelle
Informationen erwartet, denn die Analyse mit WinHex zeigt keinerlei
Probleme auf.
> hast irgendwas anderes wesentliches vergessen. Sind beide Kopien der FAT> identisch?
Die Kopien der FAT sind gleich, ja.
> Was geschieht, wenn Du (in einem Konsolenfenster) chkdsk -r aufrufst?
Reiche ich nach.
>> Was geschieht, wenn Du (in einem Konsolenfenster) chkdsk -r aufrufst?>> Reiche ich nach.
Nichts hilfreiches. Mit chkdsk /F /R kommt der Fehler, dass kein
exklusiver Zugriff auf das Laufwerk hergestellt werden kann, das lässt
sich auch nicht wirklich umgehen.
Ausgabe von normalem chkdsk:
1
I:\>chkdsk
2
Der Typ des Dateisystems ist FAT.
3
Dateien und Ordner werden überprüft...
4
Die Datei- und Ordnerüberprüfung ist abgeschlossen.
5
Windows hat auf dem Datenträger Fehler gefunden, wird diese aber
6
n, weil der Parameter /F nicht angegeben wurde.
7
Verlorene Ketten in Dateien umwandeln (J/N)? j
8
16384 Bytes in 1 wiederherstellbaren Datei(en)
9
Windows hat Probleme im Dateisystem festgestellt.
10
Führen Sie CHKDSK mit der Option /F (Fehlerbehebung) aus, um die
11
beheben.
12
13
65.421.312 Bytes Speicherplatz auf dem Datenträger insgesamt
14
32.768 Bytes in 3 Datei(en)
15
65.355.776 Bytes auf dem Datenträger verfügbar
16
17
16.384 Bytes in jeder Zuordnungseinheit
18
3.993 Zuordnungseinheiten auf dem Datenträger insgesamt
19
3.989 Zuordnungseinheiten auf dem Datenträger verfügbar
Stimmt soweit, nur die wiederhergestellten verlorenen Ketten sind
nirgendwo aufgetaucht.
Frank Bär schrieb:> Mit chkdsk /F /R kommt der Fehler, dass kein> exklusiver Zugriff auf das Laufwerk hergestellt werden kann, das lässt> sich auch nicht wirklich umgehen.
Wieso das? Solange nicht irgendein anderer Windows-Prozess auf das
Laufwerk zugreift, geht das sehr wohl. Ohne diesen repariert chkdsk
nichts, und zeit nur an, was es tun würde, wenn es könnte.
Doch, da ist noch einer.
> I:\>chkdsk /F /R
Nämlich der cmd.exe-Prozess, aus dem heraus Du das aufrufst. Für den ist
I:\ das Arbeitsverzeichnis, und das lässt er sich nicht wegnehmen.
Ändere das, so daß da steht
> C:\>chkdsk i: /F /R
und das Thema sollte sich geklärt haben.
Schon, und wie sieht dann das Medium aus? Sieh Dir mit dem Hexeditor das
(Root-?) Verzeichnis und die FAT genau an, und vergleiche mit dem, was
Du vorher hattest.
00082048 45 44 53 5F 54 45 53 32 54 58 54 20 00 B7 B5 7B 4A 3E 4A 3E 00 00 0E 07 6A 3E 04 00 4E 00 00 00 EDS_TES2TXT .·µ{J>J>....j>..N...
Der mittlere Eintrag ist entstanden, als ich EDS_TES2.TXT auf den
Massenspeicher kopiert habe. Bis auf die Zeit- und Datumsstempel
unterscheiden sich der erste und dritte Eintrag nicht.
Frank Bär schrieb:> die Fehlermeldung "Datei kann nicht gefunden werden".
Das klingt für mich nach nach Dateinamensproblemen.
Zeig doch mal den Hexdump des Verzeichniseintrages.
00082048 45 44 53 5F 54 45 53 32 54 58 54 20 00 B7 B5 7B 4A 3E 4A 3E 00 00 0E 07 6A 3E 04 00 4E 00 00 00 EDS_TES2TXT .·µ{J>J>....j>..N...
> Der mittlere Eintrag ist entstanden, als ich EDS_TES2.TXT auf den> Massenspeicher kopiert habe. Bis auf die Zeit- und Datumsstempel> unterscheiden sich der erste und dritte Eintrag nicht.
Ich habe den Verdacht, daß Dein Algorithmus zur Bestimmung der zur Datei
gehörenden Cluster nicht korrekt ist. Chkdsk hat "verwaiste Daten"
gefunden, also eine Clusterkette in der FAT, die keinem
Verzeichniseintrag zugeordnet ist.
Die letzten vier Bytes des Eintrages sind die Dateilänge, Deine Datei
"EDS_tst.txt" ist 0 Bytes lang.
Rufus Τ. Firefly schrieb:> Und also auch keinen Cluster in der FAT belegen darf ...
tut sie auch nicht.
Ich glaube aber, zu wissen, wo das Problem liegt.
Meine Clusternummern beginnen bei 0, d.h. die erste Datei landet auf
Cluster 2. Die mit Windows erstellte Datei beginnt auf 4, aber in der
FAT sieht das so aus:
Der markierte Eintrag wurde von Windows erzeugt, laut Stammverzeichnis
ist das aber Cluster 4. Das würde dafür sprechen, dass Windows die
Clusternummern ab 1 hochzählt.
Was meinst du dazu?
Deine FAT interpretiere ich so, daß vier Dateien vorhanden sind -
einschließlich des Root-Directories.
> 00016384 F8 FF FF FF FF FF *FF 0F*
FFF8 dürfte das Root-Directory sein
FFFF ?
FFFF ?
0FFF ist "Deine Datei", was so nicht stimmen kann, denn das würde
bedeuten, daß genau das die Nummer des nächsten Clusters dieser Datei
ist.
(Ich beziehe mich hier auf http://home.teleport.com/~brainy/fat16.htm,
dort "Cluster Meaning (FAT Table Entries)")
Merkwürdig.
Frank Bär schrieb:> Der letzte Eintrag (FF0F) ist von Windows erstellt worden.
Ja, aber das ist das irritierende, weil das ein auf weitere Einträge
verweisender Eintrag ist. Was steht denn in der Gegend um den
FAT-Eintrag 0x0FFF in der FAT?
Das scheint aber nicht das Problem zu sein.
Ich habe gerade mal mit WinHex im Root-Verzeichnis etwas rumgespielt.
Anfangs habe ich nur die Zeit- und Datumstempel verändert, danach war
die Datei noch lesbar. Die Änderung des Dateinamens hat es gebracht. Ich
habe von Groß- auf Kleinbuchstaben umgestellt, danach liess sich die
Datei nicht mehr öffnen. Wieder zurück auf Großbuchstaben und es geht.
Sehr merkwürdig!
Edit: Wenn ich die Datei im Filesystem als EDS_TEST.TXT anlege, statt
als EDS_test.txt, dann funktioniert das Ganze. Traumhafte
Windows-Welt...
Nun, das ist vermutlich in der FAT16-Spezifikation so spezifiziert, daß
die 8.3-Dateikürzel nur in Großbuchstaben auftreten dürfen. So werden
Doubletten unterschiedlicher Schreibweise vermieden (die auf FAT ja auch
nicht zulässig sind).
Kleinschreibung wurde erst zusammen mit "echten" Dateinamen im Rahmen
von VFAT eingeführt.
Du hast Recht. Ich habe hier "USB Mass Storage - Designing and
programming Devices and embedded hosts" neben mir liegen. In der
Beschreibung zu den Felder name und extension steht als Letztes "upper
case only."
Das muss mir wohl durch die Lappen gegangen sein.
