TFileStream Fehler

[tomkupitz]

Hallo,

ich benutze TFileStream um meine Projektdaten (fortfolgend Integer-, Extended-Werte etc.) auf die Platte zu speichern. Dazu benutze ich Read und Write. Im Feld kommt es nun in seltenen Fällen dazu, dass Dateien beschädigt sind. Das kann ich anhand von Prüfsummen gut erkennen.

Meine allgemeine Frage ist nun: Habt ihr ähnliche Erfahrungen mit TFileStream und welche Ursachen gibt es dafür (Virenscanner o.ä.)?

Danke und beste Grüße

[hoika]

Hallo,
wie groß sind die denn Dateien?

Je größer, desto mehr könnte eine Virenscanner was mit zu tun haben.

Arbeitest Du mit mehreren Threads?

[tomkupitz]

das Speichern passiert ohne weitere Threads. Die Dateien sind bis max. 10MB groß.

Beste Grüße

[scrat1979]

Ich arbeite sehr viel mit TFileStream, unter anderem um Konfigurationen zu speichern. Korrupte Dateien sind mir diesbezüglich noch nicht untergekommen.

Was bei mir immer wieder zu Fehlern führte waren „fehlerhafte“ Speicherungen welche nicht „kompatibel“ mit den jeweiligen Typen beim Einlesen waren. Da lag der Fehler dann aber VOR dem Monitor...

[Gausi]

Sind denn Probleme mit der Hardware ausgeschlossen?

[himitsu]

VirenScanner sollten doch keine Teile in Dateien ohne Rückmeldung ändern?

Ansonsten macht TFileStream nicht Schlimmes und reicht dein Zeug direkt an Windows weiter (WriteFile). Es hat auch keinen eigenen Cache, so wie z.B. die alten PascalFunktionen um AssignFile, wo dann was verschwienden könnte, wenn du nicht richtig schließt.


ABER so wie früher gibt es auch hier zwei Funktionen zum Schreiben und auch nochmal zum Lesen.
Write und BlockWrite, bzw. jetzt ebenfalls .Write und .WriteBuffer, wobei jeweils Letzeres den Erfolg prüft, außer du willst selber Prüfen, aber dann solltest du auch das Result vom Write behandeln.
z.B. Platte ist voll, oder sonstige Fehler beim Schreiben (z.B. auch wenn der Virenscanner das Schreiben verbietet)


PS: Es gibt auch TReader und TWriter. Ddie Dinger werden z.B. von der VCL/FMX verwendet, um die BinärVersion der DFM zu speichern.
Sie speichern zu jedem Wert auch das Format, validieren beim Lesen die Typen und so kann man auch eine "Zahl" lesen, egal ob es Byte, Word oder Integer ist, oder String als ANSI oder UTF-8.

[tomkupitz]

der Fehler tritt wirklich selten auf (bei uns in der Applikation nie). Doch gerade bei unseren OEMs stößt das sauer auf...

Hardwareprobleme kann ich auch nicht ausschließen.

Beste Grüße

[hoika]

Hallo,

Zitat:

VirenScanner sollten doch keine Teile in Dateien ohne Rückmeldung ändern?

Es reicht ja, das Schreiben ein kleines bissel zu "verlangsamen".
Und wenn die Software dann das Schreiben abbricht -> Dateifehler.

Abhilfe könnte sein, die Datei unter einem anderen Namen zu speichern,
und wenn das geklappt hat (Prüfsumme), die Datei umzubenennen in den richtigen Dateinamen.

[himitsu]

Zitat von hoika:

Es reicht ja, das Schreiben ein kleines bissel zu "verlangsamen".
Und wenn die Software dann das Schreiben abbricht -> Dateifehler.

Eigentlich nicht.
Du gehst hier über den FileCache des OS, außerdem wartet dein Programm auf das Ende der Schreiboperation (Write/Close), da hier keine overlapped/asynchrone API benutzt wird.
Wenn es einen Fehler gibt und die Rückgabewerte ausgewertet werden, dann gibt es eine Fehlermeldung/Exception, falls z.B. der Virenscanner oder ein defektes Laufwerk sich meldet.
Und ist das Write zurückgekommen, dann steht es im WindowsFileCache ... selbst wenn du dann schnell das Programm abschießst, so lange du nicht auch Windows hart beendest, wird immernoch gespeichert ... kommt es da nochmal zu einem Fehler, dann poppt ein Popup auf und Windows meldet sich. (eigene Erfahrung, mit defekter USB-Platte, bzw. bei Fehlbedinung)

Es gab nur einen Fall, wo ich jahrelang Datenfehler hatte, aber da war es ein defekter USB 3-Treiber für meinen Intel-Chipsatz, der auf USB-Platten und bei USB-LAN-Adaptern alle paar MB immer mal paar Byte falsch übertagen hat und das nicht merkte.
Oder natürlich die Schuld des Benutzers ... Festplatte/USBStick abziehen, bevor fertig gespeichert wurde.

[dummzeuch]

Benutzt Du .Write oder .WriteBuffer?

Falls ersteres: Prüfst Du auch den Rückgabewert, ob der komplette Buffer geschrieben wurde? Wenn nein, dürfte das das erste Problem sein.

Wir benutzen TFileStream in sehr großem Umfang und das auch noch multithreaded. Da geht normalerweise nichts verloren.

Aber wenn man nicht prüft, ob auch alles geschrieben wurde.