System.Zip Entpacken einer Datei

[zeras]

Ich nutze folgende Funktion, um eine Datei aus einer Zipdatei zu entpacken. Das klappt in den meisten Fällen gut, aber bei verschiedenen Zip-Dateien kommt die Meldung "Die angegebene Datei wurde nicht gefunden xxxx/xxxx/xxx".
Oder kann es sein, dass System.Zip nicht alle Zipversionen kennt?
Die Datei, die ich suche, liegt in einem Unterpfad.
Wenn ich eine andere Datei extrahieren will, die in der Root der Zipdatei liegt, gibt es keine Problem.
Wenn ich aber die Funktion Zip.ExtractAll nutze, wird die Datei neben allen anderen Dateien sauber extrahiert.
Nun wollte ich in System.Zip debuggen. Aber da hält der Debugger nicht an. Kann es damit zu tun haben, dass System.Zip scheibgeschützt unter den Programm Files liegt?

Delphi-Quellcode:

  Result := false;
  Zip := TZipFile.Create;
  try
    try
      Zip.Open(SrcfName, zmRead);

      if fNames2Extract.Count > 0 then begin
        for I := 0 to fNames2Extract.Count -1 do begin
          s := StringReplace((fNames2Extract[i]), '\', '/', [rfReplaceAll]); //231012-01

          //231012-01
          //Wenn Datei nicht existiert, müssen wir das mit abfangen
          try
            Zip.Extract(s, DstDir, false);  //Original
          except

            on E: Exception do
              begin
                ShowMessage(E.Message + '"' + s + '"');  //211107-01
                raise;
              end;
          end;
        end;
      end;
      result := true;
    except
      ShowMessage('Fehler bei EntzipOneFile');
    end;
    Zip.Close;
  finally
    Zip.Free;
  end;

[Uwe Raabe]

Zitat:

Zitat von zeras (Beitrag 1532618)

Nun wollte ich in System.Zip debuggen. Aber da hält der Debugger nicht an.

Hast du denn auch "Mit Debug-DCUs" in den Compiler-Optionen aktiviert?

[zeras]

Zitat:

Zitat von Uwe Raabe (Beitrag 1532620)

Zitat:

Zitat von zeras (Beitrag 1532618)

Nun wollte ich in System.Zip debuggen. Aber da hält der Debugger nicht an.

Hast du denn auch "Mit Debug-DCUs" in den Compiler-Optionen aktiviert?

Danke für den Hinweis. Jetzt kann ich weiter debuggen.

[zeras]

Das Debuggen in der System.Zip wird wohl sehr schwierig werden. Das werde ich wohl nicht hinbekommen.
Was ich gesehen habe, ist dass im Header unterschiedliche Werte stehen bei Dateien, wo es geht und Dateien, wo es nicht geht, siehe Anhänge.
Vielleicht hat einer der Spezialisten hier eine Info, ob man mit den Headerdaten schon sieht, wo es klemmt.
Das erste Bild zeigt den Header der Problemdatei. Dort ist der Wert "MadeByVersion" anders als in der Datei, wo es geht.

[mytbo]

Zitat:

Zitat von zeras (Beitrag 1532618)

Oder kann es sein, dass System.Zip nicht alle Zipversionen kennt?

Oder mal mit mORMot testen:

Delphi-Quellcode:

uses
  mormot.core.base,
  mormot.core.os,
  mormot.core.zip;

begin
  var zipRead: TZipRead := TZipRead.Create(zipFileName);
  try
    var idx: Integer := zipRead.NameToIndex(fileNameToSearch);
    if (idx >= 0)
      and zipRead.UnZip(idx, ...) then
    begin
    end;
  finally
    zipRead.Free;
  end;

Bis bald...
Thomas

[zeras]

Danke mytbo, aber ich hatte erst von Delphizip auf interne Funktionen umgestellt, da Delphizip meines Wissens nicht mehr weiterentwickelt wurde. Das wäre natürlich später eine Möglichkeit, wenn die internen dann noch nicht gehen.

Ich habe nun einmal die System.Zip lokal in mein Testprojekt kopiert und diese zu Debuggen genommen. Dabei ist mir aufgefallen, dass es Unterschiede in der Speicherung der einzelnen Dateien innerhalb der Zipdatei gibt.
Bei den Zipdateiten, wo es nicht funktioniert, ist das Trennzeichen ein Backslash, bei den Zipdateien, wo es funktioniert, ein normaler Slash.
Nun stellt sich für mich die Frage, ob das Zipprogramm (ich weiß nicht, wie die Dateien gezipt wurden) nicht nach Vorgabe zusammenpackt, oder ob Delphi hier nicht nach Solldefinition auspackt.
Ich könnte bestimmt die System.Zip ändern, aber das wäre nur eine Notlösung.

Darf man hier eine Zeile oder zwei aus der System.zip zeigen, wie es funktionieren könnte?
Wenn ich in der Funktion TZipFile.IndexOf die Backslahes durch Slashes ersetze, geht es erst einmal.

[Uwe Raabe]

Wäre es möglich eine Beispiel-Zip zu erstellen, die wir hier zum Testen verwenden können?

[TurboMagic]

Uwe, hattest du nicht mal irgendwo die URL der ZIP-Spezifikation?
Evtl. steht da was zu dieser Trennzeichengeschichte drin?

[Uwe Raabe]

https://pkware.cachefly.net/webdocs/...es/APPNOTE.TXT

[TurboMagic]

Zitat:

Zitat von Uwe Raabe (Beitrag 1532669)

https://pkware.cachefly.net/webdocs/...es/APPNOTE.TXT

:thumb:

[zeras]

Zitat:

Zitat von Uwe Raabe (Beitrag 1532655)

Wäre es möglich eine Beispiel-Zip zu erstellen, die wir hier zum Testen verwenden können?

Das kann ich wegen der darin enthaltenen Quellen leider nicht publizieren.
Auch kann ich nicht die "schlechte" Datei nehmen und einige Dateien löschen. Sobald ich wieder ein Zipprogramm zum Zippen nehme, wird der Slash eingefügt, Beispiel:

V01\compile.log -> bringt Fehler
V01/compile.log -> OK, keine Exception

Wenn eine Datei in der Root steht, dann klappt alles, da ja der Backslash fehlt.
Ich könnte ja den Teil hier posten, weiß aber nicht, ob ich das darf wegen Emba??

Ich weiß bisher nicht, mit welchem Zipprogramm die "schlechten" Dateien gezipt wurden. Das kann ich vielleicht nächste Woche herausfinden, ist aber nicht klar, da hier mehrere Kollegen gezipt haben und einige davon sind sehr kreativ.8-)

[zeras]

Zitat:

Zitat von Uwe Raabe (Beitrag 1532655)

Wäre es möglich eine Beispiel-Zip zu erstellen, die wir hier zum Testen verwenden können?

Das kann ich wegen der darin enthaltenen Quellen leider nicht publizieren.
Auch kann ich nicht die "schlechte" Datei nehmen und einige Dateien löschen. Sobald ich wieder ein Zipprogramm zum Zippen nehme, wird der Slash eingefügt, Beispiel:

V01\compile.log -> bringt Fehler
V01/compile.log -> OK, keine Exception

Wenn eine Datei in der Root steht, dann klappt alles, da ja der Backslash fehlt.
Ich könnte ja den Teil hier posten, weiß aber nicht, ob ich das darf wegen Emba??

Ich weiß bisher nicht, mit welchem Zipprogramm die "schlechten" Dateien gezipt wurden. Das kann ich vielleicht nächste Woche herausfinden, ist aber nicht klar, da hier mehrere Kollegen gezipt haben und einige davon sind sehr kreativ.8-)

In der o.g. Spezi steht folgender Text drin, d.h. dass das Zipprogramm, was genutzt wurde, nicht der Spezi entspricht oder beim Einlesen des Headers noch etwas verändert wurde. Ich habe bisher nur hier "TZipFile.IndexOf" nachgeschaut und nicht bei Zip.Open.

Zitat:

4.4.17 file name: (Variable)

4.4.17.1 The name of the file, with optional relative path.
The path stored MUST NOT contain a drive or
device letter, or a leading slash. All slashes
MUST be forward slashes '/' as opposed to
backwards slashes '\' for compatibility with Amiga
and UNIX file systems etc. If input came from standard
input, there is no file name field.

[QuickAndDirty]

Leider gibt es das oft das Hersteller von tools von standards abweichen! Wer auch immer deine Dateien gezipt hat, hat ein nicht standard konformes tool benutzt.
Ich hatte das mal bei der einem VOIP-CAPI Produkt...nennen wir es YCAPI. Das ist eine CAPI2032.DLL die angeblich ISDN conform den CAPI auf IP telefonie umsetzt.
Dann gab es immer weieder mal Abstürze oder unseres auf der CAPI programms wenn es mit YCAPI arbeitete.
Stellte sich heraus dass YCAPI nach einer DISCONNECT_B3_IND message trotzdem noch DATA_B3_CONF Messages dieser Connection im speicher ablegte...
Eindeutig nicht standard konform!

Code:

(Capi 2.0 Version 5 Seite 44)

Every DATA_B3_REQ results in a corresponding DATA_B3_CONF, with one ex-ception: after transmitting the message DISCONNECT_B3_IND to an application, COMMON-ISDN-API is not allowed to send any other message concerning this log-ical connection. Therefore the application must ensure correct management of re-sources or buffers.

Ich habe die Hersteller auf die Seite und die Zeile hingeweisen , wo steht das das nicht geht conformation messages in eine Disconnecteten Verbindung auszuliefern...
die Antwort war "DOCH DAS IST WOHL STANDARD KONFORM"... lol

Wir haben dann unser Programm so angepasst das es auch mit nicht standardkonformen CAPI2023.dll implementierungen umgehen kann...

Und du musst das vermutlich auch mit den PFADEN machen, damit du Zipdateien von diesen nicht standardkonformen programmen öffnen kannst...
Oder machs wie ich und versuch mal solche leute dazu zu bewegen nen Standard durchzulesen... und dann das Programm anzupassen.
Wie dem aucch sei mit legacy dateien könnte es ja dann trotzdem nicht funktionieren.

[zeras]

Zitat:

Zitat von QuickAndDirty (Beitrag 1532709)

Und du musst das vermutlich auch mit den PFADEN machen, damit du Zipdateien von diesen nicht standardkonformen programmen öffnen kannst...
Oder machs wie ich und versuch mal solche leute dazu zu bewegen nen Standard durchzulesen... und dann das Programm anzupassen.
Wie dem aucch sei mit legacy dateien könnte es ja dann trotzdem nicht funktionieren.

Danke für deine Infos. So geht es offenbar bei vielen Entwicklern. Jeder hat Recht und keine ändert etwas.
Die nicht konformen Dateien stammen wahrscheinlich aus der Zeit, wo man mein Programm nicht genutzt hatte. Da hat wohl jeder einen Zipper gefunden und genutzt. Ich muss nur demnächst einmal prüfen, ob es immer noch Leute gibt, die etwas anderes als mein Programm benutzen. Ist halt einfach, da man die Dateien auch lokal zippen und dann per Explorer auf unser Netzlaufwerk schieben kann. Das kann ich derzeit nicht ändern.
Da nun schon etliche Dateien auf dem Netz liegen, muss ich wie oben beschrieben, die Delphi Zip Routine ändern. Es wäre natürlich schön, wenn Emba dies auch machen würde, um kompatibler zu sein. Aber wenn man sich an den Standard hält, hat man ja alles richtig gemacht.
Danke für eure Unterstützung.

[TurboMagic]

Naja, sobald das neue Bugtracking System in ein paar Tagen verfügbar ist,
könntest du dort ja einen Feature Request dazu reinstellen, ggf. mit Verweis
auf diesen Thread bzw. einer Beschreibung dass es solche problematische Zipper
gibt.

Da wäre es aber vermutlich hilfreich wenn du rausfinden könntest welcher Zipper
das macht, dann kann man leichter testen...

[zeras]

Zitat:

Zitat von TurboMagic (Beitrag 1532733)

Naja, sobald das neue Bugtracking System in ein paar Tagen verfügbar ist,
könntest du dort ja einen Feature Request dazu reinstellen, ggf. mit Verweis
auf diesen Thread bzw. einer Beschreibung dass es solche problematische Zipper
gibt.

Habe ich zwar noch nie gemacht, kann es ja aber mal versuchen.

Zitat:

Zitat von TurboMagic (Beitrag 1532733)

Da wäre es aber vermutlich hilfreich wenn du rausfinden könntest welcher Zipper
das macht, dann kann man leichter testen...

Da ich mehrere Zipdateien mit dem Problem habe, kann ich das vielleicht herausfinden, wer diese bearbeitet hat. Sollte ich etwas herausfinden, kann ich das ja hier posten. Wird aber ein wenig Sisyphusarbeit.

[jaenicke]

Zitat:

Zitat von TurboMagic (Beitrag 1532733)

Da wäre es aber vermutlich hilfreich wenn du rausfinden könntest welcher Zipper
das macht, dann kann man leichter testen...

PowerShell bis letztes Jahr (gemeldet 2017 in Bug #48), .NET bis 4.6.1 und alle darauf aufsetzenden Tools, ...
Leider war das weit verbreitet, weshalb es durchaus Sinn macht, ein Tool zum Entpacken an der Stelle fehlertolerant zu gestalten statt sich streng an den Standard zu halten (auch wenn das natürlich korrekt ist).

[Uwe Raabe]

Ich würde es vorziehen ein Tool zu haben das solche Dateien repariert. Das kann ja auch in einer anderen Programmiersprache gemacht werden und es wäre auch für alle Systeme nutzbar - nicht nur für Delphi Programme ab Version X. Warum soll denn jedes ZIP-lesende Programm auch solche Abweichungen von der Norm verarbeiten können. Das ist doch total unökonomisch. Wenn dann nächsten Monat ein neuer Kandidat mit einer eigenwilligen Interpretation des Standards auftaucht, dann genügt eine neue Version des Tools um das für alle abzudecken. Mit Sicherheit gibt es solche Tools bereits. Man muss nur das geeignete raussuchen. Open Source wäre sicher ein Vorteil.

[QuickAndDirty]

Zitat:

Zitat von jaenicke (Beitrag 1532739)

PowerShell bis letztes Jahr (gemeldet 2017 in Bug #48), .NET bis 4.6.1 und alle darauf aufsetzenden Tools, ...

Microsoft.....Ich weiß nicht ob ich lachen soll oder weinen soll das es natürlich ein millarden schwerer konzern war der den Bug schöööön weit verbreitet hat und dann auch noch einen so Windows-Compatiblen bug...
Und ist das jetz wie mit der Windows C-Api? Verlassen sich jetzt etliche Software Hersteller darauf das der Bug weiter besteht?