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

[Jim Carrey]

Ich benutze seit Neuestem privat ZIP-Forge zum Zippen von Dateien in meinem Projekt.

Da das normale Zippen zulange dauerte habe ich auf das Zippen direkt im Speicher über einen TMemoryStream umgestellt.
Jetzt ist mir aufgefallen, dass normal geöffnete Dateien ohne besondere Schutz-Rechte nicht in den Speicher geschrieben werden können.

Genauer gesagt ist Datei Projekt.exe in Verzeichnis ABC offen und ich zippe mit Projekt.exe das Verzeichnis ABC.
Projekt.exe kann jetzt nicht gezippt werden.

Gibt es hier einen Schalter den ich einstellen kann, dass die Datei nur im Lese-Modus geöffnet wird und nicht auch im Schreibmodus?

So sieht das Originalbeispiel aus und so verwende ich es auch

Delphi-Quellcode:

var
  Archiver: TZipForge;
  ms: TMemoryStream;
begin
  // create ZipForge object
  Archiver := TZipForge.Create(nil);
  // create memory stream
  ms := TMemoryStream.Create;
  try
    // create a new archive in the memory stream (specify False to open an existing archive)
    Archiver.OpenArchive(ms, True);
    // save a file into the archive
    Archiver.AddFiles('c:\file.txt');
    // close archive
    Archiver.CloseArchive();
  except
     on E: Exception do
     begin
       Writeln('Error: ' + E.Message);
     end;
  end;
  ms.Free;
  Archiver.Free;
end.

Ohne Memorystream ist alles OK und auch normal geöffnete Dateien können gezippt werden.

[hoika]

Hallo,
hast die Version nicht mit den Quellen?

[Lemmy]

Kann das Teil nicht zufällig auch ein AddStream? Dann könntest Du das ja über den Weg selbst erledigen... auch ohne Sourcen...

[mkinzler]

Zitat:

Kann das Teil nicht zufällig auch ein AddStream?

Laut Featurelist ja:

Zitat:

Save/Load zipped data from stream

Ich habe mir mal die PE angesehen. Dort scheint es die Methode auch zu geben

[Jim Carrey]

Ich habe die Sourcen leider auch nicht.
Aber wenn man das Archiv mit einem Stream "öffnet" ZipForge1.OpenArchive(aMemoryStream, True); ... und dann Dateien "hinzufügt" ZipForge1.AddFiles(); ... ackert der intern dann nicht auch AddToStream ab?

[himitsu]

Zitat von Jim Carrey:

ackert der intern dann nicht auch AddToStream ab?

Vermutlich ja, aber da kannst DU selber den Stream öffnen und somit auch die Sharingrechte bestimmen.

[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?