Discussion :

[Radec]

Bonjour a tous.

Voila, je developpe une application d'archivage de modèles. Ces modèles sont composés de beaucoup de fichiers répartis dans des dossiers dont les noms suivent une norme.
J'ai donc choisi de compresser les différents dossiers en zip puis de calculer pour chacun un checksum. Ce checksum n'as plus qu'a etre comparé avec le checksum de la version précédente pour savoir si un fichier du dossier (et par conséquent le fichiers zip) à été modifié.
D'une version à l'autre, un dossier peut etre identique (dans le sens où tous les fichiers du dossier sont identiques) donc je m'attendais a ce que le fichiers zip qui en resulte soit identique. Ce qui n'est pas le cas.

Je me suis donc dit que c'était à cause des dates de création, de dernier accès et de dernière écriture qui ne sont pas les mèmes entre les fichiers zip. J'ai donc intégré cela à mon programme et alors les checksums ne sont toujours pas identiques.
Donc maintenant je me demande si c'est vraiment possible de faire ce que je veut:
Créer à deux instants différents deux fichiers zip ayant le mème contenu et disposant du même checksum.

Si quelqu'un a une idée elle serait la bienvenue.

[ced600]

Je dis peut être une bétise, mais le checksum n'est il pas une somme des bits du fichier zip ?
Si c'est le cas, est ce que le chemin complet du fichier rentre dans ce compte ? (ils sont différents puisque répertoires différents)
Est ce que l'écart est énorme ?

Bah sinon, il ne te reste plus qu'à comparer l'ensemble des fichiers des différents répertoires pour repérer s'il y a des modifications.

[Radec]

Le problème ici étant que les chemins sont totalement identiques !!!
Meis ton idée soulève encore un autre problème !! Youpi !!!

[ced600]

Le problème ici étant que les chemins sont totalement identiques

Dans ce cas tes 2 zip n'ont pas le même nom (ou alors tu en supprimes un avant de refaire l'autre), et toujours pareil, le nom peut il entrer en jeu dans le calcul ?

[Radec]

Dans ce cas tes 2 zip n'ont pas le même nom (ou alors tu en supprimes un avant de refaire l'autre), et toujours pareil, le nom peut il entrer en jeu dans le calcul ?

Mème pas, les fichiers sont rigoureusement identiques.
Je commence à m'arrache les cheveux.

[Radec]

En fait mon application va chercher les fichiers dans un dossier et crée les fichiers zip correspondants (dont les noms sont normalisés). Puis j'utilise PVCS pour archiver sur une base de données distante. Enfin je supprime les fichiers .zip locaux.
Lors de mes tests, je supprime un fichier dans un dossier, donc au moment d'archiver, il doit me dire qu'un des fichiers zip qu'il génère à changé. Mais au lieu de ca, tous les fichiers sont différents.

[ced600]

Je suppose que tu veux faire ton test avec le checksum car tu te dit qu'avec la taille du zip, par manque de chance avec la taille tu pourrais avoir 2 Zip de taille identique mais avec des fichiers différents.
Mais si tu vérifie l'égalité de taille à l'octet près, tu manquerais vraiment de chance pour tomber dans le cas cité plus haut non ?

Sinon te reste plus qu'à faire une liste des ficheirs avec leurs dates de création, de modifications, leur noms, et leur taille, et à vérifier s'il y a des modifications de cette liste, à chaque fois que tu vérifie le changement de version.

[ced600]

Je ne connais pas l'algorithme de compression pour les zip, mais je ne suis pas sur que la compression de fichiers soient toujours la même. Le taux de compression ne peut il pas dépendre de facteur comme la charge processeur ?
N'y a t'il pas un tas de chose qui pourrait intervenir pour modifier ne serait qu'un peu le taux de compression et donc la taille du zip ? Et donc la valeur du checksum ?

[toxycyty]

A mon avis il y a plusieurs type de compression.
Quand on utilise Winrar, on peut voir qu'il propose 6 types de compression pour un fichier .zip (compression normale, compression optimale ...)
Ca doit jouer dessus a mon avis.

[Onlava]

chaque fichier zip contient un crc32 des fichers archivés. Tu pourrais lire ce header et comparer les crc entre 2 fichiers zip. Je crois que ça pourrais même te donner le nom des fichiers qui diffèrent directos (vu qu'ils doivent etre dans le header, mais à vérifier).
a+

[Radec]

A mon avis il y a plusieurs type de compression.
Quand on utilise Winrar, on peut voir qu'il propose 6 types de compression pour un fichier .zip (compression normale, compression optimale ...)
Ca doit jouer dessus a mon avis.

En effet, il y bien plusieurs types de compression seulement dans mon appli j'ai fixé ce type de compression donc cela ne peut pas rentrer en compte dans les différences.

chaque fichier zip contient un crc32 des fichers archivés. Tu pourrais lire ce header et comparer les crc entre 2 fichiers zip. Je crois que ça pourrais même te donner le nom des fichiers qui diffèrent directos (vu qu'ils doivent etre dans le header, mais à vérifier).
a+

Je viens de comparer tous les CRC des deux fichiers et ils sont tous identiques. Enfin voila je commence à me taper la tête contre les murs.

Si je me rappèle bien mes cours de Systèmes d'exploitation, les dates (modification, dernière lecture et dernière écriture) ne sont pas stoquées dans le fichier mais dans l'inode contenant le fichier non ? D'ailleur je viens de faire le test et c'est bien le cas, les dates ne changent rien au checksum.

[ced600]

Bah sinon, tu peux tout simplement comparer les fichiers contenus dans les zip un à un.
Ils ont le même nom, et tu compares leur checksum, leur taille, leur date de création, leur date de modification.
Ensuite tu pondère chacune de ces données, et si tu estimes que au bout d'un certain nombre de changement, ils sont différents. Bref si les checksums sont diff, la taille identique, et les dates de modif diffs, alors il y a eu modification.
Mais bon si tu fais le checksum sur chacun des fichier, je pense qu'il y aura moins de différence.

[Radec]

Bah sinon, tu peux tout simplement comparer les fichiers contenus dans les zip un à un.
Ils ont le même nom, et tu compares leur checksum, leur taille, leur date de création, leur date de modification.
Ensuite tu pondère chacune de ces données, et si tu estimes que au bout d'un certain nombre de changement, ils sont différents. Bref si les checksums sont diff, la taille identique, et les dates de modif diffs, alors il y a eu modification.
Mais bon si tu fais le checksum sur chacun des fichier, je pense qu'il y aura moins de différence.

C'est en effet une des solutions qui pourrais marcher mais si je fais cela je ne respecte pas mon cahier des charges car les archives sont composées de plusieurs milliers de fichiers et la perte de temps est trop grande. Donc je vais approffondir ma recherche pour trouver quel est le problème dans mon algorithme.

[ced600]

Et si tu avais un service windows qui surveille constemment les répertoires où tu stockes les version différentes, avec la classe dont j'ai oublié le nom, tu pourrais être alerter lors de la modif d'un fichier, l'ajout, et la suppression de fichier.
Tu saurais en temps réel si c une nouvelle version, et alors tu sauras qu'il faut zipper le repertoire et stocker le zip sur le serveur.

[Keihilin]

Le problème n'est peut être pas à ce niveau, mais pourrais-tu préciser l'algo de compression (ou la librairie la cas échéant) que tu utilises ?

Je crois que certaines méthodes ne garantissent pas que le même fichier en entrée donne systématiquement le même fichier en sortie...

[Radec]

Le problème n'est peut être pas à ce niveau, mais pourrais-tu préciser l'algo de compression (ou la librairie la cas échéant) que tu utilises ?

Je crois que certaines méthodes ne garantissent pas que le même fichier en entrée donne systématiquement le même fichier en sortie...

En fait sur la première version de la compression j'utilisait SharpZipLib, ce qui marchait pas trop mal et m'offrait un bon taux de compression mais en l'occurence elle ne m'offrait pas la possibilité d'avoir les mèmes fihiers en sortie.
Je viens d'essayer la librairie System.IO.Compression et Ô miracle ca marche mais mes fichiers zip ne sont pas ouvrables par les archiveurs disponibles sur le marché (gratuit comme payants). De plus le niveau compression est pas top (enfin compression entre 1/4 et 1/5 c'est pas trop mal non plus).

Donc j'ai réglé mon problème mais il me reste à faire en sorte que mes archives crées soient ouvrables par un logiciel de compression classique car pour ma compression je ne crée pas d'en-tête pour le fichier (en gros je compresse les binaires de mes différents fichiers en un gros binaire tout moche).

Me reste plus qu'a trouver comment construire un en-tête pour le fichier et ce sera bon.

Merci à tous pour votre aide. C'est la fête dans les chaumières.