Echec en utilisant TZipFile

Version imprimable

14/03/2022, 21h44
_alx_

Echec en utilisant TZipFile

Bonsoir,
Je voudrais décomprimer des fichiers ZIP créés par l'explorateur de WIN10 (>Envoyer vers>Dossier compressé) en mode 64 bits.
Sous Alexandria (je n'ai pas essayé d'autres versions), la décompression en utilisant TZipFile de System.Zip (zip.Extract ou zip.Read) échoue au moment de la création du ''stream'' interne.
L'erreur retournée (version française) est ''élément introuvable'', peu explicite.
Quelqu'un a-t-il déjà rencontré ce problème ?
Merci d'avance.
alx.
15/03/2022, 01h08
Paul TOTH

Citation:

Envoyé par _alx_

Bonsoir,
Je voudrais décomprimer des fichiers ZIP créés par l'explorateur de WIN10 (>Envoyer vers>Dossier compressé) en mode 64 bits.
Sous Alexandria (je n'ai pas essayé d'autres versions), la décompression en utilisant TZipFile de System.Zip (zip.Extract ou zip.Read) échoue au moment de la création du ''stream'' interne.
L'erreur retournée (version française) est ''élément introuvable'', peu explicite.
Quelqu'un a-t-il déjà rencontré ce problème ?
Merci d'avance.
alx.

c'est quoi un mode 64bits ? un ZIP est un ZIP, il y a juste ZIP64 pour le support des fichiers dont la taille ne tient pas dans 32bits, mais c'est supporté par Alexandria.

"élément introuvable" c'est SGenericItemNotFound = 'Elément introuvable';...qui provient d'une liste générique...mais ça ne devrait pas se produire, TZipFile produit des erreur spécifiques EZipException

un bout de code ?
15/03/2022, 07h46
pprem

Si tu as compressé un dossier, n'oublie pas qu'il faut l'indiquer dans le nom du fichier à décompresser, sinon il ne le trouvera pas.

Citation:

Envoyé par Paul TOTH

c'est quoi un mode 64bits ? un ZIP est un ZIP, il y a juste ZIP64 pour le support des fichiers dont la taille ne tient pas dans 32bits, mais c'est supporté par Alexandria.

"mode 64 bits" veut dire qu'il s'agit d'un code Delphi compilé en 64 bits sur un Win10 64 bits !

Citation:

Envoyé par Paul TOTH

"élément introuvable" c'est SGenericItemNotFound = 'Elément introuvable';...qui provient d'une liste générique...mais ça ne devrait pas se produire, TZipFile produit des erreur spécifiques EZipException

En effet, cela ne devrait pas se produire. Au DEBUG, l'exception (difficile à tracer) a lieu dans la procédure TZipFile.Read, au moment de la création du stream interne de décompression, i.e. :
Code:

1 2 // Create Decompression stream. Stream := FCompressionHandler[TZipCompression(FFiles[Index].CompressionMethod)].Value(FStream, Self, LocalHeader);
Comme si le 'Deflate64' utilisé par Windows dans ce cas, ne pouvait être traité par Delphi ?

Citation:

Envoyé par Paul TOTH

un bout de code ?

mon code (en gros) et simplement:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 var zip: TZipFile; m: TStream; //je ne crée pas le stream hdr: TZipHeader; begin zip := TZipFile.Create; zip.Open; zip.Read(0, m, hdr); //1er fichier compressé et exception ici. // etc... end.
Merci (à Paul Toth et pprem) pour vos suggestions.
alx.

15/03/2022, 11h30
ShaiLeTroll

Open n'est pas censé avoir un nom de fichier ou un stream en entrée pour dézipper ? avec zmRead comme mode aussi ... ça compile Open sans paramètre ? surprenant si l'on se fie à la doc.
Ne pas oublier de libérer le Stream retourné par Read
15/03/2022, 11h40
_alx_

Citation:

Envoyé par ShaiLeTroll

Open n'est pas censé avoir un nom de fichier ou un stream en entrée pour dézipper ?
Ne pas oublier de libérer le Stream retourné par Read

Il y a 4 versions de TZipFile.Read, suivant que le fichier original est indiqué par son nom ou son rang dans le ZIP, ou que la sortie soit un fichier ou un stream. J'ai présenté l'un des cas, mais toutes les configurations conduisent au même problème.
Pour info, le ZIP se décomprime très bien avec 7-zip, il y a la même exception sous Delphi 10(.4.2).
alx.
15/03/2022, 11h43
_alx_

Citation:

Envoyé par ShaiLeTroll

Open n'est pas censé avoir un nom de fichier ou un stream en entrée pour dézipper ? avec zmRead comme mode aussi ... ça compile Open sans paramètre ? surprenant si l'on se fie à la doc.
Ne pas oublier de libérer le Stream retourné par Read

Pardon, j'ai répondu trop vite: dans le bout de code que j'ai donné, j'ai oublié l'argument dans le Open ! Ce n'est évidemment pas le cas dans lo code effectif.
15/03/2022, 11h51
ShaiLeTroll

Que retourne TZipFile.FileNames[0], FileCount ... faut que vous creusiez les FileInfos
15/03/2022, 12h15
_alx_

Citation:

Envoyé par ShaiLeTroll

Que retourne TZipFile.FileNames[0], FileCount ... faut que vous creusiez les FileInfos

Vous avez raison: justement, les FileInfos (sous forme du TZipHeader) sont parfaitement décodés, et l'ensemble des fichiers du zip identifiés par leur nom original, leurs longueurs comprimée et décomprimée. C'est au moment de l'exécution effective de la décompression que ça semble coincer.
Mais je me trompe peut-être.
alx.
15/03/2022, 12h48
pprem

peux-tu tester ton code avec un autre ZIP (au cas où y aurait un truc lié au contenu de celui-ci comme le gommage des fichiers ou leur taille) ?
15/03/2022, 12h49
_alx_

Le ZIP contient un fichier (une séquence video, dans un format non standard) de taille 2.4 GB, comprimé en 0.8 GB.
Et c'est là que ça coince.
En ''déboguant'' pas à pas, je trouve que le stream construit par TZipFile.Read a une valeur de Position constituée d'un nombre de ... 20 chiffres.
Je pense qu'il y a donc une erreur dans le code Delphi, en particulier dans ce cas de figure de très gros fichiers (au delà de 32 bits ?). C'est pourtant bien la compression 'Deflate64' qui est mentionnée et utilisée.
Que peut-on faire ?
alx.
15/03/2022, 13h08
_alx_

Ce n'est pas cela, car le problème survient aussi sur un petit fichier texte inclus dans le même ZIP (vérifié aussi sur d'autres ZIPs).
En d'autres termes, les ZIPS sont reconnus comme valides par Delphi et leurs structures bien reconstituées, mais la décompression ne marche pas.
alx.
15/03/2022, 13h53
pprem

Bizarre, m'en suis servi sur EggHunter en zipant / dézipant des fichiers et en bidouillant des trucs modifiés sous Windows directement sans soucis particulier.

Pour la position, il ne faut pas trop s'en préoccuper, c'est la version dézipée qu'on a dans le stream de lecture d'un fichier, faut pas y toucher.

bien entendu je n'ai pas mes sources sur cet ordinateur, te ferai un copier coller de ce que j'utilise dans la soirée ou demain
15/03/2022, 15h09
Paul TOTH
Citation:
Envoyé par _alx_

En effet, cela ne devrait pas se produire. Au DEBUG, l'exception (difficile à tracer) a lieu dans la procédure TZipFile.Read, au moment de la création du stream interne de décompression, i.e. :

Code:

1 2 // Create Decompression stream. Stream := FCompressionHandler[TZipCompression(FFiles[Index].CompressionMethod)].Value(FStream, Self, LocalHeader);

Comme si le 'Deflate64' utilisé par Windows dans ce cas, ne pouvait être traité par Delphi ?
en effet, tu peux regarder dans class constructor TZipFile.Create; les seules méthodes supportées sont zcStored et zcDeflate

et à priori Windows décide d'utiliser Deflate64 en fonction de la taille du fichier (voir ici)

d'après Wikipedia, Deflate64 est propriétaire et peu intéressant...étrange que Windows l'utilise

sous .Net c'est pareil :)
15/03/2022, 15h47
_alx_

Citation:

Envoyé par Paul TOTH

en effet, tu peux regarder dans class constructor TZipFile.Create; les seules méthodes supportées sont zcStored et zcDeflate

et à priori Windows décide d'utiliser Deflate64 en fonction de la taille du fichier (voir ici)

d'après Wikipedia, Deflate64 est propriétaire et peu intéressant...étrange que Windows l'utilise

sous .Net c'est pareil :)

Bien vu !
J'ai reconstitué l'un de mes ZIPs avec 7zip en forçant le mode ''Deflate'' au lieu de ''Deflate64''. Et là, tout marche bien.
Toujours aussi pointu Paul TOTH !
Moralité: ne pas utiliser Windows pour fabriquer des ZIPS pour Delphi. Mais, entre nous, ce serait bien aussi si Embarcadero ajoutait le mode ''Deflate64'' qui est quand même plus efficace en compression (au moins 2 fois) pour les gros fichiers ...
Merci à tous ceux qui ont contribué.
alx.
15/03/2022, 15h55
Paul TOTH

demandé

https://quality.embarcadero.com/browse/RSP-37326
15/03/2022, 16h00
_alx_

Citation:

Envoyé par Paul TOTH

demandé

https://quality.embarcadero.com/browse/RSP-37326

You're welcome!
alx.