ZIP-Forge Datei zippen im MemoryStream (geöffnete Dateien)

[Jim Carrey]

Ich habe das gerade mal so versucht

Delphi-Quellcode:

ZipForge1.OpenArchive(fmCreate);

// Statt ZipForge1.AddFiles(aFileName); nun ...

// for ... alle meine Daten
aFileStream := TFileStream.Create(aFileName, fmOpenRead); // fmOpenRead statt fmOpenWrite
ZipForge1.AddFromStream(aFileName, aFileStream);
aFileStream.Free;
// ende for

ZipForge1.CloseArchive;

Leider ist das Archiv dann leer. Ich habe bestimmt einen sau-blöden Fehler gemacht und sehe ihn nicht.
Das Archiv war nur leer, weil ich am Ende der For-Schleife noch ein aMemoryStream.SaveToFile() vom alten MemoryStream stehen hatte.


Edit: ich sehe gerade ZipForge1.AddFromStream() hat leider einen Bug und ist unbrauchbar.
Die Option ZipForge1.Options.StorePath := spRelativePath; wird bei AddFromStream komplett ignoriert.
Außer aber man entfernt durch String-Replace das BaseDir aus aFileName, dann ist es OK.

[Jim Carrey]

Das funktioniert jetzt soweit sehr gut.
Auch wenn es umständlich ist.

Delphi-Quellcode:

aMemoryStream := TMemoryStream.Create;
ZipForge1.OpenArchive(aMemoryStream, True); 

aFileStream := TFileStream.Create(aCurrItem.sSourceDirItem, fmOpenRead);
try
 ZipForge1.AddFromStream(StringReplace(aFileName, ZipForge1.BaseDir, ''), aFileStream);
finally
 aFileStream.Free;
end;

ZipForge1.CloseArchive;
aMemoryStream.SaveToFile(ZipForge1.FileName);

Einzige unschöne Nebenwirkung ist, dass wenn man große Dateien zippen möchte man die Meldung bekommt "Zu wenig Arbeitsspeicher".
Aber das ist wohl der bittere Nebengeschmack denke ich. Ab circa 500MB im Taskmanager bekomme zumindest ich die Meldung.

Dann werde ich wohl jetzt eine Art Kreuzung einbauen die bei Verzeichnissen, sagen wir mal, bis zu Größe-X mit dem FileStream zippt und sonst normal.

[Codehunter]

Zitat von Jim Carrey:

"Zu wenig Arbeitsspeicher" [....] Ab circa 500MB im Taskmanager bekomme zumindest ich die Meldung.

Nur mal so interessenhalber: Tritt der Fehler auch auf wenn du als 64 Bit kompilierst?

[Jim Carrey]

Daran habe ich noch nicht gedacht. Aber nein, da passiert es nicht.

Ich habe eben den Compiler-Schalter {$SETPEFLAGS IMAGE_FILE_LARGE_ADDRESS_AWARE} gefunden. Mit dem klappt auch das Komprimieren von 500MB+ großen Dateien.
Ohne ihn nicht.

Kann dieser Schalter irgendwelche Nebenwirkungen hervorufen?

[Jim Carrey]

Ich habe eben zufälligerweise auch mitbekommen, dass das Programm die eigene Programmdatei trotzdem nicht zippen kann, obwohl ich die Datei mit fmOpenRead in den Stream lade.
Die Fehlermeldung lautet, dass das Handle ungültig sei.

[Codehunter]

Wäre mal zu probieren, die eigene Programmdatei vor dem Zippen per ScriptingHost (ShFileOperation) zu kopieren und die kopierte Datei zu zippen. Solange eine Exe läuft, hat das System einen exklusiven Zugriff auf die Datei. Da kommst du nicht ran mit einem Programm das im Benutzerkontext läuft. Der ScriptingHost läuft im System und sollte es können.

Delphi-Quellcode:

uses Winapi.Shellapi;

function dwCopyDirFile(const Src, Dst: String; const GUI, SimpleGUI, CopyConfirmation, MkDirConfirmation, ErrorGUI: Boolean; var UserHasCancelled: Boolean): Boolean;
var
  FOS : TSHFileOpStruct;
  Flags: Word;
begin
   Flags:= 0;
   if GUI then if SimpleGUI then Flags:= Flags or FOF_SIMPLEPROGRESS
          else                   Flags:= Flags or FOF_SILENT;
   if not CopyConfirmation  then Flags:= Flags or FOF_NOCONFIRMATION;
   if not MkDirConfirmation then Flags:= Flags or FOF_NOCONFIRMMKDIR;
   if not ErrorGUI          then Flags:= Flags or FOF_NOERRORUI;
   ZeroMemory(@FOS,SizeOf(FOS));
   with FOS do begin
      wFunc := FO_COPY;
      fFlags := Flags;
      pFrom := PChar(ExcludeTrailingBackslash(Src) + #0);
      pTo := PChar(ExcludeTrailingBackslash(Dst));
   end;
   RESULT := (0 = ShFileOperation(FOS));
   UserHasCancelled:= FOS.fAnyOperationsAborted;
end;

Bzgl. des Speicherproblems dürfte es eigentlich selbsterklärend sein: Je nach dem wie die ZIP-Routinen implementiert sind alloziieren sie evtl. so viel Speicher wie die unkomprimierten Daten groß sind. Die 500 MB sind ja nur das Endresultat des Komprimierens. Bei einem 32-Bit-System wäre da spätestens bei 3 GB RAM Schluss, wahrscheinlich aber eher bei 2 GB. Es gibt richtige Streamzipper die können das besser, aber auch da ist irgendwann Sense bei 32 Bit. Auch ein Grund warum wir bei uns nur noch 64 Bit ausliefern.

[Jim Carrey]

Danke das werde ich mal ausprobieren.

Das Speicherproblem habe ich vorerst mit dem Setzen von {$SETPEFLAGS IMAGE_FILE_LARGE_ADDRESS_AWARE} behoben.
Der Speicherverbrauch geht jetzt schon einmal bis 1GB und mehr. Vorher konnte eine 500MB Datei nicht komprimiert werden, jetzt schon.