TFileStream langsam wenn kein fmCreate?

[Gruber_Hans_12345]

hallo

Ich habe zwei Anwendungen, die erste soll eine Datei erzeugen und ständig in diese schreiben (eine Art log datei)
Die zweite Anwendung öffnet diese Datei lesend, und liest diese eben zyklisch aus

Im ersten Szenario, habe ich beim erzeugen fmCreate angegeben., dadurch kann ich nicht lesend auf die Datei zugreifen aus der zweiten App und ein schreibvorgang dauert ca 4ms

Wenn ich nun aber die daten mit fmWrite or fmShareDenyNone öffne dann dauert der schreibvorgang auch nur 4ms

Sobald ich aber einmal mit der zweiten Anwendung lesend auf die Datei zugreife (es wird ein TFileStream.Crate der danach wieder mit Free freigegeben wird) dann macht auch das schrieben probleme

das heisst der selbe Schreibvorgang dauert auf einmal ca 200 ms

ist das normal?

Oder wo schaue ich falsch und machen einen Fehler?

[Uwe Raabe]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1234534)

Ich habe zwei Anwendungen, die erste soll eine Datei erzeugen und ständig in diese schreiben (eine Art log datei)
Die zweite Anwendung öffnet diese Datei lesend, und liest diese eben zyklisch aus

Der Ansatz ist per se schon mal fragwürdig. Durch den gleichzeitigen Zugriff zweier Prozesse werden die Buffer komplett unterlaufen. Das könnte deine Probleme ausmachen.

Alternative 1:
Beim Schreiben wird an eine bestehende Datei angehängt bzw. erst eine neue erzeugt. (logisch)
Beim Lesen wird eine bestehende Datei vor dem Öffnen umbenannt. Andernfalls gibt es nichts zu lesen.

Alternative 2:
Du schreibst eine Server-Anwendung, die das Schreiben und Lesen zentral übernimmt. Eventuell kann das Log in diesem Fall sogar im Speicher bleiben.

Alternative 3:
Du verwendest eine Datenbank.

Es gibt sicher noch weitere...

[Gruber_Hans_12345]

Hmmmm

Will weder ne DB noch einen Service verwenden, da das loggin schon mit der ersten programmzeile funken sollten, und auch geloggt werden sollten wenn mit der DB oder so was nicht funkt ... ohne viel overhead.

Was mir aber eben komisch vorkommt
wenn ich mit

Delphi-Quellcode:

Create(FileName, fmOpenReadWrite or fmShareDenyWrite);

starte
dann 20 * Blöcke mit ca 1000 Bytes schreibe -> dann geht das zügig

dann macht die Schreibanwendung mal nix (hat aber den Stream noch offen)

jetzt kommt die Leseanwendung und liest auf einmal die ganze Datei, und schließt den Filestream

danach geht das schreiben mit der immer noch offenen Anwendung extremst träge ...

[Sir Rufo]

Für einen reibungslosen Zugriff auf die Log-Datei, solltest du die Datei zum Schreiben öffnen, die Daten schreiben und dann die Datei wieder schließen.

Dann dürfte es auch keine gravierenden Geschwindigkeitseinbußen geben.

[sx2008]

Also TFileStream ist über jeden Verdacht erhaben denn die Klasse ist nur eine ganz dünne Schicht über den Windows-API-Funktionen CreateFile, ReadFile, WriteFile, CloseHandle.
Es gibt keinen Buffer oder irgendein Eigenleben in dieser Klasse.

Ein Virenscanner könnte auf die veränderte Logdatei reagieren und im Hintergrund einen Scanvorgang starten.
Früher haben die Virenscanner die Datei über die offizielle API ausgelesen.
Das hat manchmal dazu geführt dass die Datei für kurze Zeit nicht durch die Anwendung geöffnet werden konnte.
Heutzutage sind Virenscanner noch tiefer im Kernel verankert.
Der Virenscanner könnte deine Anwendung ohne weiteres in dem API-Aufruf blockieren bis sein Scanvorgang beendet ist.

Ich habe sowieso nie verstanden weshalb manche Virenscanner per Default ALLE Dateien scannen; also auch Logdateien und Sourcecode.
Aber das ist Einstellungssache.

[himitsu]

Zitat:

Zitat von sx2008 (Beitrag 1234562)

Ich habe sowieso nie verstanden weshalb manche Virenscanner per Default ALLE Dateien scannen; also auch Logdateien und Sourcecode.
Aber das ist Einstellungssache.

Weil sich viele Bösewichte eh nicht an die Dateiendungen halten. (sonst gäbe es ja ein .virus)

Und auch in Quellcodedateien verstecken sich gerne mal Viren, wie z.B. der schnucklige Delphi-"Virus", welcher die System.pas von Delphi 7 befallen hat.

Genauso könnte auch in Logdateien sich schädlicher "Code" verstecken, welcher z.B. in bestimmten LogViewern/LogParsern einen Buffer-Overrun auslösen könnte.

[himitsu]

Zitat:

Zitat von himitsu (Beitrag 1234567)

Weil sich viele Bösewichte eh nicht an die Dateiendungen halten. (sonst gäbe es ja ein .virus)

PS: http://www.heise.de/newsticker/meldu...o.beitrag.atom => gelingt es den Angreifern, über speziell präparierte TIFF-Grafiken, Code in die Rechner ihrer Opfer einzuschleusen.

[musicman56]

Zitat:

Zitat von Sir Rufo (Beitrag 1234551)

Für einen reibungslosen Zugriff auf die Log-Datei, solltest du die Datei zum Schreiben öffnen, die Daten schreiben und dann die Datei wieder schließen.

Dann dürfte es auch keine gravierenden Geschwindigkeitseinbußen geben.

Genauso würde ich es auch machen bzw. mache ich das auch heute noch, wenn's denn schon mal keine DB sein soll/darf/kann. Noch zu DOS-Zeiten war das schon so, und es hat im Netzwerk mit vielen Usern funktioniert. Damals waren es eben typisierte Dateien. Heute macht man das mit Streams, das ist aber schon der einzige Unterschied.

Für den Shared-Zugriff erstellt man während des Schreibvorganges eine temporäre Lock-Datei, die beispielsweise das Suffix '.$$$' hat. Wenn nun die Lockdatei existiert, wartet der Client mit dem lesen eine einstellbare Zeit (ca. 2 Sekunden) darauf, dass sie wieder verschwindet (sprich vom schreibenden Prozess gelöscht wird). Ist das nicht der Fall, hat sich der schreibende Prozess wohl verabschiedet. Dann versucht der Client vielleicht alternativ noch, die Lockdatei zu löschen. Funktioniert auch das nicht, muss wohl der Admin ran. Aber, ich kann mich - ausser bei Systemabstürzen - nicht daran erinnern.