Quel langage pour faire ça ? - Divers - Programmation
Marsh Posté le 23-01-2004 à 09:54:21
Que pour ton parcours, calcule le md5 pour chaque fichier, c'est plus rapide pour comparer ensuite
Marsh Posté le 23-01-2004 à 10:15:33
C'est une bonne id. Cependant est-ce que ça n'est pas trop pénalisant en temps d'éxecution ? Parce que calculer le md5 (ou tout autre hash) de milliers de petits fichiers, c'est ptet bcp bcp plus long que de prendre simplement leur taille, non ?
Marsh Posté le 23-01-2004 à 10:17:01
J'ai fais ça en Python il n'y a pas longtems. Tu commence pas prendre la taille des fichiers, et tu ne calcules leur md5 que pour ceux qui ont la même taille. Et bien sur, tu met les resultats en cache.
Marsh Posté le 23-01-2004 à 17:55:49
un ptit crc32 qui stocke le checksum du fichier et son chemin dans un tableau et voila c terminé
Marsh Posté le 23-01-2004 à 18:02:19
Bah il ne me semble pas, sinon de toute façon ça doit pas être difficile à programmer donc j'ai pas trop trop cherché à vrai dire.
$man a écrit : ca existe pas un programme qui trouve les doublons ? |
Marsh Posté le 23-01-2004 à 18:04:16
Arf, je sais pas encore programmer en python.
A ton avis ce que tu as programmé se transpose facilement en C, ou un autre langage ? Parce que c'est en gros ce que je veux faire. Tu entends quoi par mettre les résultats en cache ?
Kristoph a écrit : J'ai fais ça en Python il n'y a pas longtems. Tu commence pas prendre la taille des fichiers, et tu ne calcules leur md5 que pour ceux qui ont la même taille. Et bien sur, tu met les resultats en cache. |
Marsh Posté le 23-01-2004 à 22:05:19
Perl est aussi parfaitement indiqué pour ce genre de choses.
Marsh Posté le 23-01-2004 à 23:05:02
euh ... je connais pas non plus perl
Est-ce que l'environnement python est lourd à installer (genre visual studio) ? Parce qu'à la limite je peux essayer juste pour voir ...
Marsh Posté le 23-01-2004 à 23:11:00
en sh
un find qui fait le md5sum de tout ce qu'il trouve, tu tries par md5, tu vires tout ce qui a pas le meme md5 et vlan, voilà les doublons. facile
Marsh Posté le 23-01-2004 à 23:14:23
C'est vachement lourdingue de hacher tous les fichiers du disque hein..
Faut prendre la méthode à Kristoph, c'est qd même vachement mieux..
Marsh Posté le 23-01-2004 à 23:17:02
bah tu peux faire en 2 passes alors
la première en gardant les fichiers ayant la même taille, ensuite tu discrimes en fonction du md5sum
Marsh Posté le 23-01-2004 à 23:20:49
je vote Perl, ce sera plus facile que en shell avec les bibliotheque à sa disposition
Marsh Posté le 23-01-2004 à 23:22:37
Euh juste une question très bête : je veux faire un programme sous winXP là, alors sh j'ai pas, et Perl est-ce possible ? Est-ce plus adapté/plus facile que Python ?
Marsh Posté le 23-01-2004 à 23:24:51
freewol a écrit : Euh juste une question très bête : je veux faire un programme sous winXP là, alors sh j'ai pas, et Perl est-ce possible ? Est-ce plus adapté/plus facile que Python ? |
pour sh, t'es nické sauf install d'un couche unix (cygwin)
je sais pas si tu peux faire un .bat pour faire ce que tu veux
Perl ou Python, c'est toi qui voit
les deux fonctionne avec win dès que tu installes un interpreteur -> Google parce que là de tête je vois pas.
Je trouve Perl plsu adapté pour tout ce qui est traitement de fichiers, mais c'est surement parce que je le connais mieux aussi
Marsh Posté le 23-01-2004 à 23:25:42
tu pourrais dire ce que tu veux ?
tu serais pas entrain de nous dire que t'as jamais programmé une seule ligne ?
Démarrer->Rechercher et t'es parti
Marsh Posté le 23-01-2004 à 23:34:27
Bah oui c'est vrai, j'ai jamais programmé, d'ailleurs la programmation je ne sais pas ce que c'est, c'est pas un jeu fourni avec windows ?
Enfin bon si on excepte que je programme couremment en C++ et Delphi, pis que j'ai des bases en php et java.
C'est pas parce que je ne connais aucun langage "évolué" que je ne connais rien, pas cool la généralisation.
Surtout que tes deux 1er posts ne servaient à rien vu qu'on avait déjà dit que ct mieux de d'abord tester la taille des fichiers, et que ce dernier n'a guère plus d'utilité ...
Marsh Posté le 23-01-2004 à 23:35:38
je comprends pas pourquoi t'es encore entrain de déblatérer, t'as tout ce qu'il te faut pour t'y mettre
Marsh Posté le 23-01-2004 à 23:39:49
j'ai tout ce qu'il me faut ? Alors que je n'ai jamais programmé en python ni en perl, et que je ne sais pas s'il me faut que je lance dans l'un ou dans l'autre, voir si je dois rester dans un de mes langages ? Je ne vois pas où est le mal à attendre un peu plus d'indications de la part de gens un peu plus constructifs que toi.
Surtout que ma déblatération n'aurait jamais eu lieu sans tes verbiages.
Si j'ai enfrain d'une qqconque manière les règles de ce forum, libre à toi de fermer ce topic. Sinon je ne vois pas pkoi tu ne cesse d'y revenir ...
Marsh Posté le 23-01-2004 à 23:40:47
je vois aucun problème à faire le travail en C++
depuis le temps, t'aurais déjà torché le problème
Marsh Posté le 23-01-2004 à 23:43:26
moi j'en voit un gros : gérer des milliers de fichiers dans un simple fichier texte ne me semble pas très adapté.
Si je mets 10 min à faire mon prog et qu'ensuite il prend 15 min à chaque execution alors que j'aurais pu faire le prog en 1 semaine et qu'il ne prenne que 2 min par execution, je n'aurai pas l'impression d'avoir "torché le problème" comme tu dis.
Marsh Posté le 23-01-2004 à 23:47:08
je vois pas pourquoi ça serait plus rapide avec un langage qu'un autre.
Marsh Posté le 23-01-2004 à 23:48:42
freewol a écrit : moi j'en voit un gros : gérer des milliers de fichiers dans un simple fichier texte ne me semble pas très adapté. |
qui parle de fichier texte ?
Marsh Posté le 23-01-2004 à 23:49:09
taz a écrit : je vois pas pourquoi ça serait plus rapide avec un langage qu'un autre. |
IO bufferisé, sinon, heuh
boaf
Marsh Posté le 23-01-2004 à 23:49:30
Ah moins que tu ne connaisses tous les langages existants sous windows permettant de faire ça, la fait que tu ne saches pas pkoi ça serait plus rapide n'implique en aucun cas le fait que ça ne soit effectivement pas plus rapide ...
Je ne vois pas pkoi il y aurait de la vie sur mars, à quoi bon y envoyer des rovers ...
Marsh Posté le 23-01-2004 à 23:50:01
freewol a écrit : Ah moins que tu ne connaisses tous les langages existants sous windows permettant de faire ça, la fait que tu ne saches pas pkoi ça serait plus rapide n'implique en aucun cas le fait que ça ne soit effectivement pas plus rapide ... |
heuh tu pars en vrille la
Marsh Posté le 23-01-2004 à 23:53:35
Bah en C c'est le seul moyen que je connaisse pour stocker toutes les tailles des fichiers. Peut-être que tu suggères de tout stocker dans un tableau en mémoire, ça revient au même au niveau organisation, mais on doit gagner un peu de vitesse d'execution effectivement.
Ca reste cependant assez lourd à traiter, que l'on doive faire un tri ou une recherche dans ce tableau, s'il est vraiment énorme. C'est pour ça que je voudrais m'orienter vers un langage qui permette de gérer ça plus efficacement.
chrisbk a écrit : |
Marsh Posté le 23-01-2004 à 23:55:07
freewol a écrit : Bah en C c'est le seul moyen que je connaisse pour stocker toutes les tailles des fichiers. Peut-être que tu suggères de tout stocker dans un tableau en mémoire, ça revient au même au niveau organisation, mais on doit gagner un peu de vitesse d'execution effectivement. |
Une bonne table de hachage et hop c'est gagné. En tout cas c'est comme ça que j'ai fais en Python. Bien sur, en C tu vas probablement devoir la coder toi même
Marsh Posté le 23-01-2004 à 23:55:08
Euh ... oui un peu, désolé. Je vais dormir un bon coup et revenir plus frais demain.
chrisbk a écrit : |
Marsh Posté le 23-01-2004 à 23:55:46
freewol a écrit : Bah en C c'est le seul moyen que je connaisse pour stocker toutes les tailles des fichiers. Peut-être que tu suggères de tout stocker dans un tableau en mémoire, ça revient au même au niveau organisation, mais on doit gagner un peu de vitesse d'execution effectivement. |
et donc tu programmes courrament en C++ ?
Marsh Posté le 23-01-2004 à 23:56:26
Est-ce que pense que je ferais mieux d'installer un interpréteur python juste pour ce programme, plutôt que de coder ce qu'il faut pour le faire en C ?
Kristoph a écrit : |
Marsh Posté le 23-01-2004 à 23:56:37
Kristoph a écrit : |
vu qu'il programme courrament en C++ il aura bien entendu pensé de lui meme a ce que la STL peut lui offrir
Marsh Posté le 24-01-2004 à 15:50:17
ReplyMarsh Posté le 24-01-2004 à 16:51:13
Reply
Marsh Posté le 23-01-2004 à 09:50:25
Je voudrais faire un programme qui recherche les fichiers en double sur un disque dur, parce que j'en ai une très grande qté. J'avais tout d'abord pensé à faire tout bêtement un programme en C++ qui parcourt récursivement le disque en enregistrant dans un fichier texte les adresses des fichiers avec leur taille exacte, puis parcourir ce fichier et faire une comparaison bit à bit de tous les fichiers de taille identique. Mais ça me semble très lourd à la fois en temps d'éxecution et de taille mémoire, et je me demande si il ne faudrait pas mieux que j'utilise un langage un peu plus évolué avec une base de donnée
Qu'est-ce que vous en pensez ?