Problem beim Dekomprimieren mit TZDecompressionStream

[s.h.a.r.k]

Ich schreibe im Moment ja an meiner Log-Komponente und habe da ein Modul, welches die Datein in ein binäres Format schreibt. Hier mal ein Auszug, was passiert, wenn eine neue Log-Meldung ansteht, die über einen Thread geschrieben wird -- wir gehen mal davon aus, dass die Log-Datei schon existiert:

Delphi-Quellcode:

try
  Stream := TFileStream.Create(Filename, fmOpenWrite, fmShareDenyWrite);
  Stream.Seek(0, soFromEnd);
  CompressorStream := TZCompressionStream.Create(Stream);
  Writer := TWriter.Create(CompressorStream, 1024);
  try
    WriteMessage(Writer, LogMsg);
  finally
    Writer.Free();
    CompressorStream.Free();
    Stream.Free();
  end;
except
  { ... }
end;

procedure {...}WriteMessage(Writer: TWriter; Msg: TApLogMessage);
begin
  Writer.WriteListBegin();
  Writer.WriteInteger(Msg.X);
  Writer.WriteString(Msg.Y);
  // etc.
  Writer.WriteListEnd();
end;

D.h. es wird jedes mal der Stream neu geöffnet und die Daten in komprimierter Form dort abgelegt. Folgenden Ansatz habe ich für das Auslesen der Daten:

Delphi-Quellcode:

Stream := TFileStream.Create(FFilename, fmOpenRead);
Stream.Seek(0, soFromBeginning);

DecompressorStream := TZDecompressionStream.Create(Stream);
DecompressorStream.Seek(0, soFromBeginning);

MemoryStream := TMemoryStream.Create();
BufferBytes := DecompressorStream.Read(Buffer, 1024);
while (BufferBytes > 0) do
begin
  MemoryStream.SetSize(MemoryStream.Size + BufferBytes);
  MemoryStream.Write(Buffer, BufferBytes);
  BufferBytes := DecompressorStream.Read(Buffer, 1024);
end;
MemoryStream.Position := 0;

// SetLength(S, MemoryStream.Size);
// MemoryStream.Read(PChar(@S[1])^, MemoryStream.Size);

Reader := TReader.Create(MemoryStream, 1024);
Reader.ReadSignature();
i := Reader.ReadInteger();
s := Reader.ReadString();

Das Problem beim Auslesen ist, dass nur Datenmüll raus kommt und somit nichts sinnvolles im MemoryStream landet. Dies schlägt allerdings erst beim Reader durch, wenn dieser versucht etwas zu lesen. Die beiden kommentieren Zeilen habe ich eingefügt um mal zu schauen, was denn im MemoryStream steht -> Hieroglyphen.

Kann es daran liegen, dass ich beim Auslesen alles auf einmal lesen will und beim Schreiben das immer nur Etappenweise mache? Eine andere Erklärung habe ich eigentlich nicht dafür.

[stahli]

Ich weiß nicht, ob Dein SetSize so passt.
Ich de(komprimiere) komplette Files, das ist wohl etwas einfacher.
Vielleicht findest Du hier irgend etwas hilfreiches...

[s.h.a.r.k]

Irgendwie hatte ich schon geahnt, dass sowas kommt :mrgreen: Das Problem ist, dass ich die Log-Meldungen aber instant wegschreiben will bzw. muss, da das Programm ja abschmieren kann und meine Log-Komponenten nicht dann ja nicht mehr unbedingt schreiben kann. Muss mir mal eine Test-App basteln...

[Luckie]

Also ich würde die Datei nur bei Programm Beendigung komprimieren. Ich weiß nicht wie viele Logmeldungen du da reinschreibst, aber für mich wären das ziemlich viele Schreib- und Lesezugriffe.

[s.h.a.r.k]

Das hatte ich mir auch schon überlegt, aber was passiert, wenn die Anwendung zwischendrin komplette krepiert? Habe ich dann nicht eine korrupte Datei, wenn der Stream nicht sauber geschlossen wird? Sind dann auch wirklich alle Daten geschrieben?

Das gleiche Problem habe ich dann aber auch, wenn die Datei weiter beschrieben werden soll.

[blackfin]

Mit nem Puffer aus nem Decompression-Stream zu lesen halte ich für gefährlich...was, wenn du einen nicht-dekomprimierbaren Block erwischst?
Warum nutzt du nicht einfach "CopyFrom" ?

Delphi-Quellcode:

CompressorStream := TZCompressionStream.Create(Stream);
MemoryStream := TMemoryStream.Create();
MemoryStream.CopyFrom(CompressorStream,0);
FreeAndNil(CompressorStream) ;
MemoryStream.Seek(0,soFromBeginning) ;

[Luckie]

Hm, ja. Also öffnen, schreiben, schließen. Und nicht öffnen, dekomprimieren, schreiben, komprimieren, schließen. Und beim Log schreiben, sollte es nicht abstürzen. Aber wenn du nicht beim Log schreiben komprimierst, hast du weniger Lese- und Schreibzugriffe während des Log schreibens. Weil ich habe immer ein ungutes Gefühl, wenn man so übermäßig viel Lese- und Schreibzugriffe hat. stell dir vor, du hast ein Programm und die Festplatte ist nur am Rattern.

[s.h.a.r.k]

Ich hab noch nie mit Streams gearbeitet :stupid: Vielleicht ist meine Frage bzw. der Code daher auch eher dumm. Das kann ich leider schlecht beurteilen. Daher kann ich das CopyFrom(..., 0) auch nicht.

Zitat:

Zitat von Luckie (Beitrag 1112628)

Weil ich habe immer ein ungutes Gefühl, wenn man so übermäßig viel Lese- und Schreibzugriffe hat. stell dir vor, du hast ein Programm und die Festplatte ist nur am Rattern.

Kann ich voll und ganz nachvollziehen und gebe dir da auch recht. Ich will halt keine korrupte Datei. Daher das ständige öffnen und schließen.

Muss mich dies bzgl einfach mal einlesen bzw. ein paar Tests machen. Ich weiß nicht warum, aber ich bin immer davon ausgegangen, dass es Probleme mit der Datei gibt, wenn man in den Stream schreibt, der aber nicht korrekt geschlossen wird -- Beispiel hierfür wäre, dass das Programm sich abschießt oder auch vom User abgeschossen wird. Will halt keine korrupte Datei haben.

Zitat:

Zitat von Luckie (Beitrag 1112628)

Hm, ja. Also öffnen, schreiben, schließen. Und nicht öffnen, dekomprimieren, schreiben, komprimieren, schließen. Und beim Log schreiben, sollte es nicht abstürzen. Aber wenn du nicht beim Log schreiben komprimierst, hast du weniger Lese- und Schreibzugriffe während des Log schreibens.

Nur das verstehe ich nich so ganz. Nochmals zu meinem Code oben: der obere Code ist in meiner Log-Komponente integriert. Dieser schreibt eben die einzelnen Meldungen in einen ZCompressionStream, welcher wiederrum in eine TFileStream schreibt. Ganz unabhängig davon gibt es den Log-Reader-Code, der in einem anderen Programm werkelt und eben alles ausliest. Wird ja nur beim Schreiben komprimiert und erst beim lesen dekomprimiert. Oder wo genau liegt hier das Problem? Die Log-Datei will ich allerdings schon komprimiert ablegen, da die Datei sonst schon recht groß wird, was ich umgehen will.

-- Edit

Zitat:

Zitat von blackfin (Beitrag 1112627)

Mit nem Puffer aus nem Decompression-Stream zu lesen halte ich für gefährlich...was, wenn du einen nicht-dekomprimierbaren Block erwischst?
Warum nutzt du nicht einfach "CopyFrom" ?

Delphi-Quellcode:

CompressorStream := TZCompressionStream.Create(Stream);
MemoryStream := TMemoryStream.Create();
MemoryStream.CopyFrom(CompressorStream,0);
FreeAndNil(CompressorStream) ;
MemoryStream.Seek(0,soFromBeginning) ;

Danke dir :thumb: Ein voller Erfolg!!!

[blackfin]

kannst du mir evtl. mal eine Mini-Test-App bezüglich des Problems hochladen? Ich kann das dann mal bei Gelegenheit analysieren und evtl. den Fehler sehen....ich arbeite viel mit den TZ-Streams, teilweise laufen hier in meiner 3D-Spiele-Demo sogar bis zu 100 Compress- / Decompress-Streams in Threads über einen Firebird Read-/WriteBLOB-Algorithmus parallel...
Wenns D2006 oder D2009-kompatibler Code ist, schau ich mir das gerne mal an...

[s.h.a.r.k]

Zitat:

Zitat von blackfin (Beitrag 1112633)

kannst du mir evtl. mal eine Mini-Test-App bezüglich des Problems hochladen? Ich kann das dann mal bei Gelegenheit analysieren und evtl. den Fehler sehen....ich arbeite viel mit den TZ-Streams, teilweise laufen hier in meiner 3D-Spiele-Demo sogar bis zu 100 Compress- / Decompress-Streams in Threads über einen Firebird Read-/WriteBLOB-Algorithmus parallel...
Wenns D2006 oder D2009-kompatibler Code ist, schau ich mir das gerne mal an...

Hast mein Edit gesehen? Kann die Test-App nochmals schnell auf den fehlerhaften Code umbauen. Hatte nur die Pufferung umgstrickt, schon hats geklappt. Einen Moment...