System.Zip Entpacken einer Datei

[zeras]

Zitat von Uwe Raabe:

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.

[zeras]

Zitat von Uwe Raabe:

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.

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 von QuickAndDirty:

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 von 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.

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

Zitat von TurboMagic:

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 von TurboMagic:

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 von jaenicke:

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?