Bonjour,
 
j'aimerais vérifier si deux fichier sont identique. Pour cella j'ai écris cette méthode :
 

 
Que je teste sur deux fichiers txt identiques (copier/coller) mais dans deux répertoire différents. Or les résultats sont différents pour les deux fichiers.  
 
Où est ce que je me goure ?
 
Merci

file.getAbsolutePath().getBytes()

c'est le chemin du fichier ça

du coup tu compares les chemins, qui sont fatalement différents

Comme l'a dit brisssou, là tu compares les chemins des fichiers et non leur contenu.
 
Attention quand même, une fonction de hashage c'est bien pour déterminer que 2 fichiers sont différents, mais ce n'est pas suffisant pour dire si les 2 fichiers sont identiques...
 
Je m'explique :
 - si les hash de 2 fichiers sont différents alors on peut dire que les 2 fichiers sont différents
 - si les hash de 2 fichiers sont identiques :
     - soit les fichiers sont identiques
     - soit les fichiers sont différents et on a affaire à une collision
 
Donc si les hash sont identiques il faut comparer le contenu des fichiers.

En effet, et comme pour calculer le hash il faut quand même lire le fichier en entier... Autant lire les 2 fichiers en entier, en parallèle, pour faire la comparaison. Bloc par bloc hein, pas besoin de tout stocker en mémoire.

 
Oui. Mais non. Une des applications serra la recherche de doublons dans mes photos. C'est à dire plusieurs milliers de fichiers.  
 
Mais j'ai trouvé sur le web une classe pour calculer le hash d'un fichier.  

Ok, donc en résumé:
 
Tu calcules le hash de chaque photo une seule fois et tu le stockes quelque part.
Quand une nouvelle photo est ajoutée, si tu remarques qu'une autre photo avait le même hash, tu les compares byte par byte pour vérifier qu'elles sont vraiment identiques.
 
En n'oubliant donc pas que deux photos différentes peuvent avoir le même hash! Heureusement c'est rare donc le nombre de comparaisons byte par byte sera limité.

À noter :
 
* La gestion de l'exception n'est pas la meilleure - je serais tenté de dire qu'elle n'est pas correcte;
* Détail : getMD5 n'est peut-être pas le meilleur choix de nom de méthode. Un "compute" serait sémantiquement plus précis.

C'est vrai que la méthode devrait plutôt lever une Exception (même Runtime) plutôt que renvoyer Null sinon bonjour les NPE

Humm, pour ce genre d'exception (NoSuchAlgorithmException, CharsetNotFound, ...) qui relèvent plus de l'erreur de programmation ou de configuration, j'ai aussi tendance à les logger et les trapper sans les remonter quand c'est la seule exception de possible de la méthode.

Pourquoi s'embêter à mettre une gestion d'exception autour de cette méthode alors qu'on sait pertinemment que ça n'arrivera pas.

Mais c'est un autre débat.

Il n'y même pas besoin de comparer tout le fichier byte à byte en fait.
J'ai fais le test en limitant la comparaison au premier kilo octet des fichiers et ça rend le même résultat.
En fait j'avais le même besoin, donc je me suis amusé à faire le programme qui cherche tous les doubons dans le fichiers images (jpg, gif, png et bmp)

En effet, la probabilité que 2 fichiers différents aient à la fois le même hash et commencent de la même façon est très faible, voire nulle.

J'ai même essayé avec des valeurs plus petites et ça passe mais le gain en temps n'est pas énorme.

J'ai pas beaucoup de photo sur mon PC mais en scannant tous mes disques, je tombe quand même sur 24000 images
dont 8000 doublons... (beaucoup de logos et d'images dans des docs en plusieurs langues)

Juste en limitant la comparaison bit à bit, je suis passé d'environ 5 minutes à moins de 2 minutes

Je ne suis pas statisticien mais effectivement à chaque byte lu la probabilité de collision est d'autant plus faible et c'est bien possible qu'elle soit infime après comparaison d'1 Ko de données.
La probabilité de collision est encore plus faible en utilisant SHA-1 (160 bits) au lieu de MD5 (128 bits).
 
Bien sûr quand je parle de comparer byte par byte, c'est via un buffer histoire d'accélérer les choses.

 
Fais tourner !