cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 2019
-
19 nov. 2006 à 21:14
cs_Patrice99
Messages postés1221Date d'inscriptionjeudi 23 août 2001StatutMembreDernière intervention 9 septembre 2018
-
13 avril 2010 à 08:26
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
cs_Patrice99
Messages postés1221Date d'inscriptionjeudi 23 août 2001StatutMembreDernière intervention 9 septembre 2018 13 avril 2010 à 08:26
Non, IE6 n'est plus supporté depuis 1 ou 2 ans, pour les mises à jour de code source, Chrome n'est pas supporté non plus, par contre FireFox est supporté (pour ceux qui ne veulent pas de IE7 ou IE8).
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 12 avril 2010 à 23:08
Re,
J'ai oublié de joindre Regsvr32.exe au zip pour enregistrer dllActX_VBz11.dll qui gère les mots de passe. Je corrige ça tout de suite.
Cordialement.
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 12 avril 2010 à 22:42
ReBonjour les Administrateurs,
J'ai trouvé comment faire la mise à jour. En fait avec un autre navigateur internet, j'obtiens bien le bouton "Terminer". Il semblerait donc qu'il n'est plus possible de mettre à jour un code à partir d'IE6. C'est le navigateur que j'utilisais quand je n'obtenais pas le bouton "Terminer". A vérifier ! Mais si c'est le cas, il serait sympa de le préciser quelque part, car s'appliquer à faire des commentaires et possibilité d'enregistrer ou mettre à jour et de devoir tout recommencer, c'est pas au top. Ok IE6 c'est dépassé, mais quand-même !
Cordialement.
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 12 avril 2010 à 19:21
Bonjour les Administrateurs,
Je voudrais mettre à jour cette source, mais j'obtiens toujours le message :
"Attention : Votre source n'est pas encore en ligne !
Afin de finaliser votre participation veuillez ajouter au minimum 3 mots clef puis valider votre saisie en cliquant sur le bouton "Terminer" ci-dessus à gauche.
Merci"
les mots clef sont renseignés mais je n'obtiens jamais le bouton "Terminer"
Comment faire ????? pour la Xème fois je tape un texte d'expliaction pour arriver à ce message , Grrrrrrrrrrrrr
Merci
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 9 janv. 2010 à 17:40
Merci beaucoup, Black Dragon Odt, pour tes amabilités sur mon travail.
Je les renvoie à Jack qui a fait le plus gros boulot à l'origine.
L'endroit où tu veux faire ça me plait bien, j'ai hâte de voir.
Et quand bien même le cryptage sera basique, c'est pas un soucis.
Sachant que même 1 cryptage hyper sophistiqué ne résitera à aucun hacker chevronné. Ce n'est pas là l'essentiel, c'est seulement qu'il ferme la porte à l'utilisateur curieux qui n'ira pas plus loin.
Et dans ce cas la protection satisfera 80% de la population.
Cordialement.
Black Dragon Odt
Messages postés17Date d'inscriptionvendredi 2 février 2007StatutMembreDernière intervention 9 janvier 2010 9 janv. 2010 à 17:03
En effet Yan, en faisant un cryptage des données on n'est plus compatible avec les logiciels tiers (sauf en ne mettant pas de mot de passe).
J'ai fait pas mal de recherches sur le net et je ne trouve absolument aucune information indiquant comment protéger un fichier de type zip par mot de passe; certaines classes (notamment des ocx) incluent pourtant cette fonction de style :
- ZipProtect = 1
- ZipPassWord = "mot de passe"
Le cryptage que je pense faire est toutefois basique pour le moment (addition de codes ascci) et ne ralentira pas le traitement puisque je pense l'inclure dans les routines qui convertissent les données ASCII=>ISO / ISO=>ASCII.
De fait, ces quelques modifications minimes ne détruiront pas le magnifique travail que tu as fourni cher Yan :)
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 9 janv. 2010 à 16:44
Désolé, je n'ai vraiment pas le temps de revoir ce sujet, qui, pourtant m'intéresse.
Ceci dit, effectivement en ajoutant un "cryptage" avant compression et "décryptage" après décompression on obtient le but visé mais ça doit allourdir le temps global de traitement et ça m'est plus conforme avec la norme Zip et donc éventuellement incompatible avec des logiciels tiers.
Autre piste : si on accepte de négliger la norme des fichiers zip, (je vous l'ai jointe, Black Dragon Odt et Compaore : Structures-et-métodes_zip.txt) on pourrait peut-être aussi penser à interprêter le CRC32 des fichiers avant de les écrire dans le zip, et pour la décompression lors de sa lecture. En effet en modifiant le CRC32 de chaque fichier du zip d'une valeur correspondant à 1 mot de passe, les fichiers deviendraient illisibles (enfin seulement pour l'utilisateur !). Bien sûr il s'agirait d'un bricolage qui n'aurait pas valeur de protection puissante. Je ne l'ai pas testée, je ne sais même pas si elle est réalisable (on est déjà limité par la valeur de Long), mais dans l'affirmative, elle serait trés rapide au cryptage et décryptage.
Piste pour Compaore : pour rendre le zip obtenu par ma classe incompatible avec WinZip et Winrar ... et autres logiciels tiers, ce qui est l'inverse de ce que j'ai recherché dans l'écriture de ce code, il te suffit de changer la signature : EndOFCentralDirSignature (0x06054b50) par une autre valeur que seule la classe saura interprêter et les logiciels tiers ne reconnaitront plus le fichier zip comme un fichier zip. C'est du BRICOLAGE mais ça peut répondre à ton besoin.
@ + Cordialement.
Black Dragon Odt
Messages postés17Date d'inscriptionvendredi 2 février 2007StatutMembreDernière intervention 9 janvier 2010 8 janv. 2010 à 15:12
Bon après quelques recherches il semblerait que la gestion de mot de passe ne soit pas prise en compte sans ZLib :(
Je m'oriente donc sur un "cryptage" de données via un mot de passe, mais n'étant pas à temps plein dessus ça risque de prendre queques jours.
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 31 déc. 2009 à 16:18
Bonjour Compaore et Black Dragon Odt,
et Merci d'apprécier cette classe. Compaore Passes-moi ton mail en message privé pour que je t'adresse la dernière version, mais "brute de pommes!". En effet je n'ai pas retravaillé dessus depuis longtemps alors je ne l'ai plus bien en tête pour la diffuser sur VBF.
Oui, il manque pas mal de petites choses et notamment la protection par mot de passe. Je la ferai plus tard, quand j'y retoucherai, mais entre-temps si quelqu'un l'a fait je suis aussi preneur !
Black Dragon Odt, je regarderai tes modif avec intérêt après les fêtes.
En attendant Meilleurs voeux à tous.
Cordialement.
Yan35
Black Dragon Odt
Messages postés17Date d'inscriptionvendredi 2 février 2007StatutMembreDernière intervention 9 janvier 2010 31 déc. 2009 à 15:29
J'avais bricolé la classe d'origine pour intégrer un mot de passe dans le zip. J'essairais de modifier la classe de Yan pour en faire autant après les fêtes. Je mettrais ici les modifications.
Bonne fin d'année.
cs_compaore
Messages postés2Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention31 décembre 2009 31 déc. 2009 à 10:20
BOnjour,
jai bien parcouru ta classe clszip. elle est vraiment bien elaboré et tres bien documenté.
Aussi, je voudrais la dernière version de cette classe et je voudrais bien proteger mon fichier zip par un mot de passe. c'est a dire : saisir un mot de passe pour le zid et à la decompression saisir l meme mot de pass.
merci
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 19 oct. 2009 à 19:18
Re Black Dragon Odt,
Excuses moi pour ma faible réactivité (je n'étais pas là ce WE), je viens juste de t'envoyer ma dernière version de ma classe Zip. Merci de me faire des commentaires.
Cette version n'ai pas finie, c'est pourquoi je ne la diffuse pas.
Cordialement.
Black Dragon Odt
Messages postés17Date d'inscriptionvendredi 2 février 2007StatutMembreDernière intervention 9 janvier 2010 16 oct. 2009 à 15:10
Re Yan.
Je viens de refaire un essai et là j'ai atteint 40 minutes pour encapsalue mon fichier de 2Go. Je n'ai pas trouvé dans le code la façon d'occulter le calcul du CRC32 (si ça te revient ...). D'autre part, en ajout postérieur d'un fichier dans 1 zip contenant ce fichier de 2Go j'ai un plantage lors de l'écriture qui me shoote tout le zip (peut-être qu'en occultant le crc32 ça résoudra la problème ?).
Pour info : blackdragon@orbedutemps.net si tu peux m'envoyer la version que tu utilise
Cordialement.
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 13 oct. 2009 à 20:05
Re Black Dragon,
Pour la durée excessive de l'encapsulage, c'est principalement lié au calcul du CRC32 qui réalise, si mes souvenirs sont bons, une lecture octet par octet du fichier source, qui dépasse quand-même 2Go !, puis une autre lecture pour l'encapsulage, là par block de mémoire en fonction de ta fraction.
Si je me rappelle j'ai dû regrouper les 2 lectures, dans la version suivante, en 1 car je ne passe pas autant de temps, mais c'est vrai que c'est quand-même long.
Regarde le code, je crois avoir mis une option pour éviter le calcul du CRC32. Si tu ne réutilises pas ton zip final avec des logiciels commerciaux qui te jetteront si tu n'as pas le CRC32, tu peux gagner un temps considérable en occultant ce calcul (au détriment de la fiabilité, bien sûr!) ...
Pour le calcul de GetFileSize de plus de 2 Go, c'est exactement ce que j'avais trouvé dans des sources de Renfield, ça marche impeccable.
Cordialement.
Black Dragon Odt
Messages postés17Date d'inscriptionvendredi 2 février 2007StatutMembreDernière intervention 9 janvier 2010 13 oct. 2009 à 14:47
Re Yan.
Je me suis aussi heurté au problème de lecture de taille de très gros fichiers à cause du "long" justement. Voici le code qui retourne la vraie longueur d'un fichier même suprérieur à 4 Go ... si ça peut aider pour la suite.
En tout cas l'encapsulable d'un fichier d'environ 2go m'a pris pas mal de temps en division de la mémoire libre par 6 (environ 20 minutes) mais c'est mieux que pas d'encapsulage du tout :)
Private Const FILE_SHARE_READ As Long = &H1
Private Const GENERIC_READ As Long = &H80000000
Private Const OPEN_EXISTING As Long = 3
Private Const OPEN_ALWAYS As Long = 4
Private Const INVALID_HANDLE_VALUE As Long = &HFFFFFFFF
Private Declare Function APIGetFileSize Lib "kernel32.dll" Alias "GetFileSize" (ByVal hFile As Long, ByRef lpFileSizeHigh As Long) As Long
Private Declare Function CloseHandle Lib "kernel32.dll" (ByVal hObject As Long) As Long
Private Declare Function CreateFile Lib "kernel32.dll" Alias "CreateFileA" (ByVal lpFileName As String, ByVal dwDesiredAccess As Long, ByVal dwShareMode As Long, ByRef lpSecurityAttributes As Any, ByVal dwCreationDisposition As Long, ByVal dwFlagsAndAttributes As Long, ByVal hTemplateFile As Long) As Long
Private Declare Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)
Public Function GetFileSize(ByRef vsFilePath As String) As Currency
Dim hFile As Long
Dim xnFileSize(1) As Long
hFile = CreateFile(vsFilePath, GENERIC_READ, FILE_SHARE_READ, ByVal 0&, OPEN_EXISTING, 0, 0)
If hFile <> INVALID_HANDLE_VALUE Then
xnFileSize(0) = APIGetFileSize(hFile, xnFileSize(1))
CopyMemory GetFileSize, xnFileSize(0), LenB(GetFileSize)
GetFileSize = GetFileSize * 10000
CloseHandle hFile
End If
End Function
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 13 oct. 2009 à 01:02
ReSalut Black Dragon,
Si tu peux utiliser cette clase avec ton astuce, tant mieux, car je n'ai pas le temps de redescendre dans ce code en ce moment. Mais à y réfléchir un peu, je crois me rappeler que les fichiers > à la taille du maxi positif de Long (2.147.486.647) plantaient à cause du calcul de leur taille par l'API GetFileSize qui est limitée à Long et des déplacements par SetFilePointer que j'ai remplacées par des fonctions écrites à base de ces API et d'une astuce trouvée dans des codes de RENFIELD que j'avais adaptée à mes besoins pour ne plus être limité dans ces tailles de fichiers. Dans le même temps j'avais aussi remplacé tous les ReadFile et WriteFile par des API ce qui touchait énormément le code à de nombreux endroits ..... et là je ne sais plus où. Cependant, comme annoncé précédemment, si tu retrouves à nouveau des problèmes, je pourrais t'envoyer la dernière version de ma classe avant que je la rediffuse (c'est à dire dans pas mal de temps!).
Cordialement. Et Merci de ton intérêt pour ce code.
Black Dragon Odt
Messages postés17Date d'inscriptionvendredi 2 février 2007StatutMembreDernière intervention 9 janvier 2010 12 oct. 2009 à 17:16
Bon en fait ça fonctionne. J'ai remplacé mon zlib.dll dans system32 par le tien et ça résoud le problème. Il semblerait que ta version soit bien plus récente que la mienne.
J'ai juste une erreur 7 (mémoire insuffisante) dans la procédure bigFiles à cet endroit :
lgMax = lgmem.dwAvailPhys / 4 'mémoire physique dispo/4 pour sécu sur le reste appli et les autres applis
If nSize > lgMax Then 'dimension des tableaux d'octets, si taille fichier > à mémoire raisonnable à utiliser
ReDim arrByte(1 To lgMax)
... alors que j'ai 3Go de RAM et 2% utilisé ... va comprendre. J'ai remplacé /4 par /6 et ça passe. Je pense que je fait une implémentation de +2 sur erreur 7 limité de /4 => /10
En tout cas sacré bon boulot que tu as fais là ! Merci ;)
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 12 oct. 2009 à 14:51
Salut Black Dragon,
Effectivement, je ne sais pas encore complètement compresser des fichiers de grande taille mais j'avais bien travaillé les sources de Jack pour empacter dans le fichier final .zip des gros fichiers, et ça marche. Je l'utilise moi-même tous les jours pour des sauvegardes qui font régulièrement > 4Go et qui incluent parfois des fichiers de plus de 2 Go. Par contre, cette source est déjà vieille et je n'ai plus toute en tête aujourd'hui, mais je crois que j'utilise une version que je n'ai pas rediffusée car je ne l'avais pas entièrement finie au niveau des exemples d'utilisation ni débugguée. Mais je crois que j'avais modifié des passages de code sur l'empactage, notamment en utilisant beaucoup plus d'API.
Si tu le souhaites, je peux te l'envoyer "brute de pommes" sur une adresse mail, car je suis sur toute autre chose actuellement et ne uis donc pa prêt de la diffuser tant que je ne l'ai pas revue.
Cordialement.
Black Dragon Odt
Messages postés17Date d'inscriptionvendredi 2 février 2007StatutMembreDernière intervention 9 janvier 2010 12 oct. 2009 à 11:07
Salut Yan,
J'ai sauté sur ta source car je me heurte à un gros problème depuis quelques temps: je n'arrive à intégrer un fichier de grosse taille ( > 2Go) et j'ai vu dans tes commentaires que tu pouvais si ne n'est les zipper, tout du moins les empacter. Or, chez moi ça ne fonctionne pas : le programme semble ignorer ces fichiers dans la création du zip.
Si il y a une solution je suis prenneur.
Merci d'avance.
OverBillion
Messages postés15Date d'inscriptionmercredi 24 septembre 2003StatutMembreDernière intervention14 mars 2008 14 mars 2008 à 22:09
d'accord!
de mon coté, j'ai en tête quelques tests que je vais essayer pour comprendre comment que cela puisse fonctionner ou même pourquoi que cela ne fonctionne pas dans mon projet.
Mais d'ici tout cela, je vais continuer mon projet avec la zlib.dll dans le sys32!
Merci à toi!
Cordialement,
et à une prochaine fois, peut-être! :)
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 14 mars 2008 à 10:32
Bonjour OverBillion,
Je vois que je n'avais pas bien compris ton 1° message lors de ma réponse précédente. Comme toi je ne comprends pourquoi dans certaines situations la classe fonctionne avec la Zlib dans l'app.path, car sauf la manipulation citée dans ma réponse précédente, la zlib doit obligatoirement être dans sys32. Je ferai des essais pour voir ! mais pas tout de suite.
Cependant, tout dépend des méthodes que tu utilisais dans la classe lorsque ça fonctionnait, car seules les fonctions de compression ou d'extraction font appel à zlib, alors le simple appel du commentaire ou du catalogue du zip peut fonctionner sans la zlib et probablement d'autres fonctions que je n'ai plus en tête.
Une nouvelle version sera bientôt publiée, quand j'aurais un peu de temps et résolu un bug. Elle permettra justement, entre-autres (mais ce n'est pas la fonction la + interessante) de ne plus utiliser zlib si cette dll n'est pas présente dans sys32 ou de l'utiliser si présente, sachant que l'utilisation en pur VB (sans zlib) est beaucoup plus lente !
Cordialement
OverBillion
Messages postés15Date d'inscriptionmercredi 24 septembre 2003StatutMembreDernière intervention14 mars 2008 14 mars 2008 à 03:13
Allo,
Merci pour ta rapidité de réponse.
Ma première surprise était (et est encore) la suivante:
Le source offert ici est capable d'extraire d'un zip en se servant du Zlib.dll qui lui est directement dans le dossier du projet (App.Path) et ce sans aucune mention particulière dans les déclarations d'appel dans la classe et sans présence aucune dans le sys32.
Je prend tel que tel, cette classe. Je l'incorpore dans mon projet. Ensuite dans une form, je fais appel à la fonction d'extraction (ExtractSingleFile)
et zoup ...une erreur (File not found Zlib.dll) survient.
Seule façon rapide de palier à ce bug: déposer la dll dans le sys32.
En premier lieu, je n'ai pas de problème à utiliser le sys32.
Où j'accroche, c'est le mystère pour moi de ne pas comprendre comment ce source fonctionne à merveille avec la dll dans le App.Path
Tandis que dans mon projet, je dois la mettre dans le sys32...
Autrement dit: Comment cela se fait-il que ce source soit capable de ne pas dépendre du sys32 pour fonctionner?
car dans la classe, aucune déclaration d'appel particulière laisse penser que le VB va prendre cette dll à même le dossier du projet.....
Sinon, c'est sur que je la met dans le sys32 et je n'ai plus de problème à décompresser..mais ca n'élucide pas pour autant ce que pour moi est un mystère totale! :D
Cordialement (moi aussi)
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 13 mars 2008 à 10:33
Bonjour OverBillion,
Effectivement cette classe fait appel à la Zlib.dll pour la compression et décompression, il faut donc que cette dll soit placer dans le répertoire system32 de windows pour fonctionner.
Néanmoins si tu veux placer cette dll ailleurs, il faudra que tu modifies les déclarations d'appel à la Zlib et leur indiquer le chemin complet où figure la zlib, comme suit :
origine :
Private Declare Function Compress_Byte_Long_Byte Lib "zlib.dll" Alias .....
qu'il faudra modifier en :
Private Declare Function Compress_Byte_Long_Byte Lib "Disque:\chemin\zlib.dll" Alias .....
Ceci pour toutes les déclarations faisant appel à la zlib.
Je n'ai testé que la fonction extraction qui fonctionne en délocalisant la Dll ainsi, mais tout le reste doit suivre.
Ceci dit, je ne comprends pas trop où est le problème de placer la zlib dans windows\system32,
Pourrais-tu me dire ?
Cordialement.
OverBillion
Messages postés15Date d'inscriptionmercredi 24 septembre 2003StatutMembreDernière intervention14 mars 2008 13 mars 2008 à 03:26
Allo,
Lorsque que j'extrais des fichiers à partir d'un zip avec ce source, tout fonctionne très bien du premier coup.
Or, si j'ajoute à mon projet la classe clsZip (clsybZip.cls) alors je dois obligatoirement mettre ZLib.dll dans le dossier système de Windows.
Alors voilà ma question:
Comment ce source fait-il pour fonctionner sans que Zlib.dll soit dans le système de Windows et que mon projet lui doit l'avoir absolument là?
Merci d'avance
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 12 avril 2007 à 01:15
Bonjour,
Suite à 1 message de djborie65, j'ai trouvé 1 bug dans la méthode FileRemoveFromZip. Je diffuserai sa correction dans quelques temps avec d'autres bricoles, mais dans l'immédiat pour corriger ce bug qui empêche dans certains cas de fermer le fichier zip d'origine lu puis de le renommer, il faut ajouter :
Close #Fh
juste après le Erase tabFiles
afin que le fichier lu soit refermé dans les cas où le fichier demandé à détruire n'a pas été trouvé.
liryc078
Messages postés1Date d'inscriptionlundi 5 mars 2007StatutMembreDernière intervention 6 mars 2007 6 mars 2007 à 14:08
Merci à yan35 pour cette classe et l'aide qu'il a pu m'apporter via messages privés.
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 27 déc. 2006 à 03:15
Si tu le souhaites RAFANEL, (et les autres bien sûr) voici l'adresse d'infos sur la zLib http://www.zlib.net/manual.html La partie que je n'ai pas encore bien appréhendée est l'utilisation de plusieurs blocks dans Deflate pour gérer les gros fichiers (à découper en plusieurs morceaux en fonction de la mémoire dispo sur la machine). J'ai bien vu qu'on pouvait le faire mais je n'ai pas eu le temps d'approfondir la méthode. Je l'ai préparée avec bigFiles_Deflate mais c'est pas encore au point et j'ai d'autres priorités vu que je compresse déjà des fichiers de 150 Mo...
cs_rafanel
Messages postés21Date d'inscriptionlundi 17 mars 2003StatutMembreDernière intervention 8 mars 2012 20 nov. 2006 à 12:48
merci de tes explications,
faire moi suivre (ftp ou mail) ta doc en anglais je pourrais peu être élucider le pb.
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 20 nov. 2006 à 11:31
Merci Patrice99, mais je ne suis pas passé à vb Net et je n'en dispose pas.
Cependant, je pense que ma classe doit pouvoir gérer des fichiers > à 2 Go sur 1 partition NTFS, mais je n'ai pas encore fait le test.
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 20 nov. 2006 à 11:18
Merci EBArtSoft, j'irais voir. Ca répondra peut-être à mon besoin de compresser un gros fichier.
yan35
Messages postés185Date d'inscriptiondimanche 29 juin 2003StatutMembreDernière intervention20 juin 2013 20 nov. 2006 à 10:36
Salut RAFANEL,
En relisant bien mes commentaires et ceux dans ma source tu verras qu'il y a 2 aspects à la gestion des gros fichiers :
- le premier, que j'ai complétement traité, est de pouvoir lire et écrire des fichiers ZIP de grande taille. Ce que les classes de Jack ne pouvaient pas faire car elles conservaient en mémoire le tableau des données des fichiers zippés jusqu'à écriture de la collection à la fin, ce qui finissait par saturer la mémoire et renvoyait l'erreur n° 7; d'autre part pour le dézippage, la fonction zGetCentralDirEndPos devait remplir un tableau qui saturait la mémoire lorsque le fichier à lire était trop gros, ma fonction ybGetCentralDirEndPos utilise les API ReadFile ... et je ne lis que l'élément recherché à savoir signature EndOfCentralDir pour comparaison, ce qui est beaucoup plus rapide et économe en ressources ;
- le second, que je n'ai pas encore su traité mais dont je m'affranchis par une pirouette est de zipper 1 gros fichier. En fait, il faut fournir un tableau d'octet pour rentrer dans la Zlib (sub Compress) et donc on retombe dans le même problème de capacité mémoire. Il existe surement un moyen d'entrer et ressortir de la Zlib autrement mais je n'ai pas encore trouvé et toute la doc à ce sujet est en Anglais, je le lis mais boff boff. Alors comme je ne souhaitais pas bloquer si je rencontrais un gros fichier parmi 1 série d'autres fichiers à zipper, je calcule le crc de ce gros fichier (ce qui est long !) et je l'empacte dans le Zip mais sans compression, comme ça le Zip est plus gros mais compatible avec d'autres logiciels de Zippage.
Si quelqu'un peut m'aider là-dessus, je suis preneur.
En attendant, j'espère que ma classe répondra à tes besoins.
cs_Patrice99
Messages postés1221Date d'inscriptionjeudi 23 août 2001StatutMembreDernière intervention 9 septembre 2018 20 nov. 2006 à 10:06
Pour dépasser les 2Go sur NTFS en DotNet, voir ici :
www.vbfrance.com/code.aspx?ID=36613
econs
Messages postés4030Date d'inscriptionmardi 13 mai 2003StatutMembreDernière intervention23 décembre 200824 20 nov. 2006 à 09:11
Jack ne répond pas aux messages privés. Continue à poser des questions sur sa source. C'est plus sûr.
cs_rafanel
Messages postés21Date d'inscriptionlundi 17 mars 2003StatutMembreDernière intervention 8 mars 2012 20 nov. 2006 à 09:02
salut yan
A merci de prendre en compte ma demande de pourvoir zipper de gros fichiers car ça fait plusieurs fois que je pose cette question à jack mais jamais de réponse.
Je suis impatient de voir ton source.
@+
TR
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 19 nov. 2006 à 21:14
13 avril 2010 à 08:26
12 avril 2010 à 23:08
J'ai oublié de joindre Regsvr32.exe au zip pour enregistrer dllActX_VBz11.dll qui gère les mots de passe. Je corrige ça tout de suite.
Cordialement.
12 avril 2010 à 22:42
J'ai trouvé comment faire la mise à jour. En fait avec un autre navigateur internet, j'obtiens bien le bouton "Terminer". Il semblerait donc qu'il n'est plus possible de mettre à jour un code à partir d'IE6. C'est le navigateur que j'utilisais quand je n'obtenais pas le bouton "Terminer". A vérifier ! Mais si c'est le cas, il serait sympa de le préciser quelque part, car s'appliquer à faire des commentaires et possibilité d'enregistrer ou mettre à jour et de devoir tout recommencer, c'est pas au top. Ok IE6 c'est dépassé, mais quand-même !
Cordialement.
12 avril 2010 à 19:21
Je voudrais mettre à jour cette source, mais j'obtiens toujours le message :
"Attention : Votre source n'est pas encore en ligne !
Afin de finaliser votre participation veuillez ajouter au minimum 3 mots clef puis valider votre saisie en cliquant sur le bouton "Terminer" ci-dessus à gauche.
Merci"
les mots clef sont renseignés mais je n'obtiens jamais le bouton "Terminer"
Comment faire ????? pour la Xème fois je tape un texte d'expliaction pour arriver à ce message , Grrrrrrrrrrrrr
Merci
9 janv. 2010 à 17:40
Je les renvoie à Jack qui a fait le plus gros boulot à l'origine.
L'endroit où tu veux faire ça me plait bien, j'ai hâte de voir.
Et quand bien même le cryptage sera basique, c'est pas un soucis.
Sachant que même 1 cryptage hyper sophistiqué ne résitera à aucun hacker chevronné. Ce n'est pas là l'essentiel, c'est seulement qu'il ferme la porte à l'utilisateur curieux qui n'ira pas plus loin.
Et dans ce cas la protection satisfera 80% de la population.
Cordialement.
9 janv. 2010 à 17:03
J'ai fait pas mal de recherches sur le net et je ne trouve absolument aucune information indiquant comment protéger un fichier de type zip par mot de passe; certaines classes (notamment des ocx) incluent pourtant cette fonction de style :
- ZipProtect = 1
- ZipPassWord = "mot de passe"
Le cryptage que je pense faire est toutefois basique pour le moment (addition de codes ascci) et ne ralentira pas le traitement puisque je pense l'inclure dans les routines qui convertissent les données ASCII=>ISO / ISO=>ASCII.
De fait, ces quelques modifications minimes ne détruiront pas le magnifique travail que tu as fourni cher Yan :)
9 janv. 2010 à 16:44
Ceci dit, effectivement en ajoutant un "cryptage" avant compression et "décryptage" après décompression on obtient le but visé mais ça doit allourdir le temps global de traitement et ça m'est plus conforme avec la norme Zip et donc éventuellement incompatible avec des logiciels tiers.
Autre piste : si on accepte de négliger la norme des fichiers zip, (je vous l'ai jointe, Black Dragon Odt et Compaore : Structures-et-métodes_zip.txt) on pourrait peut-être aussi penser à interprêter le CRC32 des fichiers avant de les écrire dans le zip, et pour la décompression lors de sa lecture. En effet en modifiant le CRC32 de chaque fichier du zip d'une valeur correspondant à 1 mot de passe, les fichiers deviendraient illisibles (enfin seulement pour l'utilisateur !). Bien sûr il s'agirait d'un bricolage qui n'aurait pas valeur de protection puissante. Je ne l'ai pas testée, je ne sais même pas si elle est réalisable (on est déjà limité par la valeur de Long), mais dans l'affirmative, elle serait trés rapide au cryptage et décryptage.
Piste pour Compaore : pour rendre le zip obtenu par ma classe incompatible avec WinZip et Winrar ... et autres logiciels tiers, ce qui est l'inverse de ce que j'ai recherché dans l'écriture de ce code, il te suffit de changer la signature : EndOFCentralDirSignature (0x06054b50) par une autre valeur que seule la classe saura interprêter et les logiciels tiers ne reconnaitront plus le fichier zip comme un fichier zip. C'est du BRICOLAGE mais ça peut répondre à ton besoin.
@ + Cordialement.
8 janv. 2010 à 15:12
Je m'oriente donc sur un "cryptage" de données via un mot de passe, mais n'étant pas à temps plein dessus ça risque de prendre queques jours.
31 déc. 2009 à 16:18
et Merci d'apprécier cette classe. Compaore Passes-moi ton mail en message privé pour que je t'adresse la dernière version, mais "brute de pommes!". En effet je n'ai pas retravaillé dessus depuis longtemps alors je ne l'ai plus bien en tête pour la diffuser sur VBF.
Oui, il manque pas mal de petites choses et notamment la protection par mot de passe. Je la ferai plus tard, quand j'y retoucherai, mais entre-temps si quelqu'un l'a fait je suis aussi preneur !
Black Dragon Odt, je regarderai tes modif avec intérêt après les fêtes.
En attendant Meilleurs voeux à tous.
Cordialement.
Yan35
31 déc. 2009 à 15:29
Bonne fin d'année.
31 déc. 2009 à 10:20
jai bien parcouru ta classe clszip. elle est vraiment bien elaboré et tres bien documenté.
Aussi, je voudrais la dernière version de cette classe et je voudrais bien proteger mon fichier zip par un mot de passe. c'est a dire : saisir un mot de passe pour le zid et à la decompression saisir l meme mot de pass.
merci
19 oct. 2009 à 19:18
Excuses moi pour ma faible réactivité (je n'étais pas là ce WE), je viens juste de t'envoyer ma dernière version de ma classe Zip. Merci de me faire des commentaires.
Cette version n'ai pas finie, c'est pourquoi je ne la diffuse pas.
Cordialement.
16 oct. 2009 à 15:10
Je viens de refaire un essai et là j'ai atteint 40 minutes pour encapsalue mon fichier de 2Go. Je n'ai pas trouvé dans le code la façon d'occulter le calcul du CRC32 (si ça te revient ...). D'autre part, en ajout postérieur d'un fichier dans 1 zip contenant ce fichier de 2Go j'ai un plantage lors de l'écriture qui me shoote tout le zip (peut-être qu'en occultant le crc32 ça résoudra la problème ?).
Pour info : blackdragon@orbedutemps.net si tu peux m'envoyer la version que tu utilise
Cordialement.
13 oct. 2009 à 20:05
Pour la durée excessive de l'encapsulage, c'est principalement lié au calcul du CRC32 qui réalise, si mes souvenirs sont bons, une lecture octet par octet du fichier source, qui dépasse quand-même 2Go !, puis une autre lecture pour l'encapsulage, là par block de mémoire en fonction de ta fraction.
Si je me rappelle j'ai dû regrouper les 2 lectures, dans la version suivante, en 1 car je ne passe pas autant de temps, mais c'est vrai que c'est quand-même long.
Regarde le code, je crois avoir mis une option pour éviter le calcul du CRC32. Si tu ne réutilises pas ton zip final avec des logiciels commerciaux qui te jetteront si tu n'as pas le CRC32, tu peux gagner un temps considérable en occultant ce calcul (au détriment de la fiabilité, bien sûr!) ...
Pour le calcul de GetFileSize de plus de 2 Go, c'est exactement ce que j'avais trouvé dans des sources de Renfield, ça marche impeccable.
Cordialement.
13 oct. 2009 à 14:47
Je me suis aussi heurté au problème de lecture de taille de très gros fichiers à cause du "long" justement. Voici le code qui retourne la vraie longueur d'un fichier même suprérieur à 4 Go ... si ça peut aider pour la suite.
En tout cas l'encapsulable d'un fichier d'environ 2go m'a pris pas mal de temps en division de la mémoire libre par 6 (environ 20 minutes) mais c'est mieux que pas d'encapsulage du tout :)
Au plaisir ;)
------------------------------------------------------------------------------------------------------------------
Private Const FILE_SHARE_READ As Long = &H1
Private Const GENERIC_READ As Long = &H80000000
Private Const OPEN_EXISTING As Long = 3
Private Const OPEN_ALWAYS As Long = 4
Private Const INVALID_HANDLE_VALUE As Long = &HFFFFFFFF
Private Declare Function APIGetFileSize Lib "kernel32.dll" Alias "GetFileSize" (ByVal hFile As Long, ByRef lpFileSizeHigh As Long) As Long
Private Declare Function CloseHandle Lib "kernel32.dll" (ByVal hObject As Long) As Long
Private Declare Function CreateFile Lib "kernel32.dll" Alias "CreateFileA" (ByVal lpFileName As String, ByVal dwDesiredAccess As Long, ByVal dwShareMode As Long, ByRef lpSecurityAttributes As Any, ByVal dwCreationDisposition As Long, ByVal dwFlagsAndAttributes As Long, ByVal hTemplateFile As Long) As Long
Private Declare Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)
Public Function GetFileSize(ByRef vsFilePath As String) As Currency
Dim hFile As Long
Dim xnFileSize(1) As Long
hFile = CreateFile(vsFilePath, GENERIC_READ, FILE_SHARE_READ, ByVal 0&, OPEN_EXISTING, 0, 0)
If hFile <> INVALID_HANDLE_VALUE Then
xnFileSize(0) = APIGetFileSize(hFile, xnFileSize(1))
CopyMemory GetFileSize, xnFileSize(0), LenB(GetFileSize)
GetFileSize = GetFileSize * 10000
CloseHandle hFile
End If
End Function
13 oct. 2009 à 01:02
Si tu peux utiliser cette clase avec ton astuce, tant mieux, car je n'ai pas le temps de redescendre dans ce code en ce moment. Mais à y réfléchir un peu, je crois me rappeler que les fichiers > à la taille du maxi positif de Long (2.147.486.647) plantaient à cause du calcul de leur taille par l'API GetFileSize qui est limitée à Long et des déplacements par SetFilePointer que j'ai remplacées par des fonctions écrites à base de ces API et d'une astuce trouvée dans des codes de RENFIELD que j'avais adaptée à mes besoins pour ne plus être limité dans ces tailles de fichiers. Dans le même temps j'avais aussi remplacé tous les ReadFile et WriteFile par des API ce qui touchait énormément le code à de nombreux endroits ..... et là je ne sais plus où. Cependant, comme annoncé précédemment, si tu retrouves à nouveau des problèmes, je pourrais t'envoyer la dernière version de ma classe avant que je la rediffuse (c'est à dire dans pas mal de temps!).
Cordialement. Et Merci de ton intérêt pour ce code.
12 oct. 2009 à 17:16
J'ai juste une erreur 7 (mémoire insuffisante) dans la procédure bigFiles à cet endroit :
lgMax = lgmem.dwAvailPhys / 4 'mémoire physique dispo/4 pour sécu sur le reste appli et les autres applis
If nSize > lgMax Then 'dimension des tableaux d'octets, si taille fichier > à mémoire raisonnable à utiliser
ReDim arrByte(1 To lgMax)
... alors que j'ai 3Go de RAM et 2% utilisé ... va comprendre. J'ai remplacé /4 par /6 et ça passe. Je pense que je fait une implémentation de +2 sur erreur 7 limité de /4 => /10
En tout cas sacré bon boulot que tu as fais là ! Merci ;)
12 oct. 2009 à 14:51
Effectivement, je ne sais pas encore complètement compresser des fichiers de grande taille mais j'avais bien travaillé les sources de Jack pour empacter dans le fichier final .zip des gros fichiers, et ça marche. Je l'utilise moi-même tous les jours pour des sauvegardes qui font régulièrement > 4Go et qui incluent parfois des fichiers de plus de 2 Go. Par contre, cette source est déjà vieille et je n'ai plus toute en tête aujourd'hui, mais je crois que j'utilise une version que je n'ai pas rediffusée car je ne l'avais pas entièrement finie au niveau des exemples d'utilisation ni débugguée. Mais je crois que j'avais modifié des passages de code sur l'empactage, notamment en utilisant beaucoup plus d'API.
Si tu le souhaites, je peux te l'envoyer "brute de pommes" sur une adresse mail, car je suis sur toute autre chose actuellement et ne uis donc pa prêt de la diffuser tant que je ne l'ai pas revue.
Cordialement.
12 oct. 2009 à 11:07
J'ai sauté sur ta source car je me heurte à un gros problème depuis quelques temps: je n'arrive à intégrer un fichier de grosse taille ( > 2Go) et j'ai vu dans tes commentaires que tu pouvais si ne n'est les zipper, tout du moins les empacter. Or, chez moi ça ne fonctionne pas : le programme semble ignorer ces fichiers dans la création du zip.
Si il y a une solution je suis prenneur.
Merci d'avance.
14 mars 2008 à 22:09
de mon coté, j'ai en tête quelques tests que je vais essayer pour comprendre comment que cela puisse fonctionner ou même pourquoi que cela ne fonctionne pas dans mon projet.
Mais d'ici tout cela, je vais continuer mon projet avec la zlib.dll dans le sys32!
Merci à toi!
Cordialement,
et à une prochaine fois, peut-être! :)
14 mars 2008 à 10:32
Je vois que je n'avais pas bien compris ton 1° message lors de ma réponse précédente. Comme toi je ne comprends pourquoi dans certaines situations la classe fonctionne avec la Zlib dans l'app.path, car sauf la manipulation citée dans ma réponse précédente, la zlib doit obligatoirement être dans sys32. Je ferai des essais pour voir ! mais pas tout de suite.
Cependant, tout dépend des méthodes que tu utilisais dans la classe lorsque ça fonctionnait, car seules les fonctions de compression ou d'extraction font appel à zlib, alors le simple appel du commentaire ou du catalogue du zip peut fonctionner sans la zlib et probablement d'autres fonctions que je n'ai plus en tête.
Une nouvelle version sera bientôt publiée, quand j'aurais un peu de temps et résolu un bug. Elle permettra justement, entre-autres (mais ce n'est pas la fonction la + interessante) de ne plus utiliser zlib si cette dll n'est pas présente dans sys32 ou de l'utiliser si présente, sachant que l'utilisation en pur VB (sans zlib) est beaucoup plus lente !
Cordialement
14 mars 2008 à 03:13
Merci pour ta rapidité de réponse.
Ma première surprise était (et est encore) la suivante:
Le source offert ici est capable d'extraire d'un zip en se servant du Zlib.dll qui lui est directement dans le dossier du projet (App.Path) et ce sans aucune mention particulière dans les déclarations d'appel dans la classe et sans présence aucune dans le sys32.
Je prend tel que tel, cette classe. Je l'incorpore dans mon projet. Ensuite dans une form, je fais appel à la fonction d'extraction (ExtractSingleFile)
et zoup ...une erreur (File not found Zlib.dll) survient.
Seule façon rapide de palier à ce bug: déposer la dll dans le sys32.
En premier lieu, je n'ai pas de problème à utiliser le sys32.
Où j'accroche, c'est le mystère pour moi de ne pas comprendre comment ce source fonctionne à merveille avec la dll dans le App.Path
Tandis que dans mon projet, je dois la mettre dans le sys32...
Autrement dit: Comment cela se fait-il que ce source soit capable de ne pas dépendre du sys32 pour fonctionner?
car dans la classe, aucune déclaration d'appel particulière laisse penser que le VB va prendre cette dll à même le dossier du projet.....
Sinon, c'est sur que je la met dans le sys32 et je n'ai plus de problème à décompresser..mais ca n'élucide pas pour autant ce que pour moi est un mystère totale! :D
Cordialement (moi aussi)
13 mars 2008 à 10:33
Effectivement cette classe fait appel à la Zlib.dll pour la compression et décompression, il faut donc que cette dll soit placer dans le répertoire system32 de windows pour fonctionner.
Néanmoins si tu veux placer cette dll ailleurs, il faudra que tu modifies les déclarations d'appel à la Zlib et leur indiquer le chemin complet où figure la zlib, comme suit :
origine :
Private Declare Function Compress_Byte_Long_Byte Lib "zlib.dll" Alias .....
qu'il faudra modifier en :
Private Declare Function Compress_Byte_Long_Byte Lib "Disque:\chemin\zlib.dll" Alias .....
Ceci pour toutes les déclarations faisant appel à la zlib.
Je n'ai testé que la fonction extraction qui fonctionne en délocalisant la Dll ainsi, mais tout le reste doit suivre.
Ceci dit, je ne comprends pas trop où est le problème de placer la zlib dans windows\system32,
Pourrais-tu me dire ?
Cordialement.
13 mars 2008 à 03:26
Lorsque que j'extrais des fichiers à partir d'un zip avec ce source, tout fonctionne très bien du premier coup.
Or, si j'ajoute à mon projet la classe clsZip (clsybZip.cls) alors je dois obligatoirement mettre ZLib.dll dans le dossier système de Windows.
Alors voilà ma question:
Comment ce source fait-il pour fonctionner sans que Zlib.dll soit dans le système de Windows et que mon projet lui doit l'avoir absolument là?
Merci d'avance
12 avril 2007 à 01:15
Suite à 1 message de djborie65, j'ai trouvé 1 bug dans la méthode FileRemoveFromZip. Je diffuserai sa correction dans quelques temps avec d'autres bricoles, mais dans l'immédiat pour corriger ce bug qui empêche dans certains cas de fermer le fichier zip d'origine lu puis de le renommer, il faut ajouter :
Close #Fh
juste après le Erase tabFiles
afin que le fichier lu soit refermé dans les cas où le fichier demandé à détruire n'a pas été trouvé.
6 mars 2007 à 14:08
27 déc. 2006 à 03:15
La partie que je n'ai pas encore bien appréhendée est l'utilisation de plusieurs blocks dans Deflate pour gérer les gros fichiers (à découper en plusieurs morceaux en fonction de la mémoire dispo sur la machine). J'ai bien vu qu'on pouvait le faire mais je n'ai pas eu le temps d'approfondir la méthode. Je l'ai préparée avec bigFiles_Deflate mais c'est pas encore au point et j'ai d'autres priorités vu que je compresse déjà des fichiers de 150 Mo...
20 nov. 2006 à 12:48
faire moi suivre (ftp ou mail) ta doc en anglais je pourrais peu être élucider le pb.
20 nov. 2006 à 11:31
Cependant, je pense que ma classe doit pouvoir gérer des fichiers > à 2 Go sur 1 partition NTFS, mais je n'ai pas encore fait le test.
20 nov. 2006 à 11:18
20 nov. 2006 à 10:36
En relisant bien mes commentaires et ceux dans ma source tu verras qu'il y a 2 aspects à la gestion des gros fichiers :
- le premier, que j'ai complétement traité, est de pouvoir lire et écrire des fichiers ZIP de grande taille. Ce que les classes de Jack ne pouvaient pas faire car elles conservaient en mémoire le tableau des données des fichiers zippés jusqu'à écriture de la collection à la fin, ce qui finissait par saturer la mémoire et renvoyait l'erreur n° 7; d'autre part pour le dézippage, la fonction zGetCentralDirEndPos devait remplir un tableau qui saturait la mémoire lorsque le fichier à lire était trop gros, ma fonction ybGetCentralDirEndPos utilise les API ReadFile ... et je ne lis que l'élément recherché à savoir signature EndOfCentralDir pour comparaison, ce qui est beaucoup plus rapide et économe en ressources ;
- le second, que je n'ai pas encore su traité mais dont je m'affranchis par une pirouette est de zipper 1 gros fichier. En fait, il faut fournir un tableau d'octet pour rentrer dans la Zlib (sub Compress) et donc on retombe dans le même problème de capacité mémoire. Il existe surement un moyen d'entrer et ressortir de la Zlib autrement mais je n'ai pas encore trouvé et toute la doc à ce sujet est en Anglais, je le lis mais boff boff. Alors comme je ne souhaitais pas bloquer si je rencontrais un gros fichier parmi 1 série d'autres fichiers à zipper, je calcule le crc de ce gros fichier (ce qui est long !) et je l'empacte dans le Zip mais sans compression, comme ça le Zip est plus gros mais compatible avec d'autres logiciels de Zippage.
Si quelqu'un peut m'aider là-dessus, je suis preneur.
En attendant, j'espère que ma classe répondra à tes besoins.
20 nov. 2006 à 10:06
www.vbfrance.com/code.aspx?ID=36613
20 nov. 2006 à 09:11
20 nov. 2006 à 09:02
A merci de prendre en compte ma demande de pourvoir zipper de gros fichiers car ça fait plusieurs fois que je pose cette question à jack mais jamais de réponse.
Je suis impatient de voir ton source.
@+
TR
19 nov. 2006 à 21:14
Remplace aisement compress/decompress
@+