Bonjour a tous,
Je cherche a trouver une fonction java qui me permettrai d'identifier un fichier de facon unique sans se fier à son path ni même à son nom. C'est a dire que 2 fichiers, de nom different et pas placé au meme endroit sur le disque auront la meme clé si leur contenu est identique... Je pense qu'une fonction dehachage comme celle doit deja exister, si vous la connaissez ca avancerai bien mon projet.
Merci d'avance

précise pourquoi tu veux utiliser ça, j'ai l'impression que tu pars dans une direction douteuse (MD5 ou inode).

je veux pouvoir identifier un fichier sur le réseau. J'ai un projet pour les cours c'est de faire un logiciel de partage de fichier. J'aimerai donc reconnaitre un fichier en fonction de son contenu et pas de son chemin... Voilà pourquoi je veux utiliser ca.

oké, algo de hachage alors, MD5 par exemple.

pareil

Tiens y a eu un topic similaire il y a quelques semaines mais je ne le retrouve pas

Attention quand meme: si 2 fichiers ont un code de hashage differents, ils sont differents. Mais si ils ont code identique, ca ne veut pas forcement dire dire que ce sont les memes fichiers...

 
bin c'est l'aglo de hashage qui est mauvais alors

 
il a raison pour md5 mais la probabilite que ca arrive est infime

Bin non Le hashage, de base, il va partir sur un modulo (2^128 pour MD5, je crois), donc y a forcément une probabilité un jour que 2 fichiers différents aient le même hashage.
De toute façon, pour passer d'un fichier de 3 Mo à un hashage de 128 bits, t'es obligé d'avoir de la perte d'infos. Ou alors t'as trouvé ZE algo de compression ultime et tu m'intéresses

 
et les coco, merci de me prendre pour un neuneu. J'ai jamais parler de MD5 moi hein
 
et puis bon c'est clair que si il fait un hash de 128bits sur un fichier de 3mo faut pas trop rêver ...
 
La seule chose que je voulais dire c'est que si la probabilité qu'un meme has correspondent à deux fichier différents soit trop 'important' (=risque d'arriver) c'est que l'algo est inadapté à l'utilisation, stou

Ba vu comment tu maîtrises StringTokenizer, j'me méfie maintenant

Moi je voulais juste dire qu'il peut effectivement utiliser un algo de hashage pour etre sur que 2 fichiers sont differents.
Mais si l'algo de hash dis que 2 fichiers sont egaux, alors il n'y a pas d'autre moyen de comparer ces 2 fichiers octet par octet afin d'etre sur qu'ils sont egaux.
C'est marrant mais je m'etait pose la question il y a quelques jours pour un probleme assez similaire. J'ecris un programme qui a besoin d'effectuer enormement de comparaison de chaines et je cherchais la methode la plus rapide pour le faire. Je suis alle fouiner dans le code de la classe String et j'ai regarde l'implementation de la methode equals() et j'ai ete surpris de voir qu'ils n'utilisent pas le code de hashage pour faire la comparaison... Si quelqu'un peut me dire pourquoi je suis preneur  

 
et quel algo de hashage miraculeux tu utilises?
parce que meme si le hashage est bon, la probabilite infime existe toujours  

Oué, première chose : toutes les chaines qui apparaissent dans le code source (constantes immédiates) sont "internalized" ce qui veut dire qu'elle ne seron jamais dupliquées en mémoire (les Strings sont immuables) mais que si un veut construire une nouvelle chaine représentant la même séquence de caractères, java réutilisara la chaine déjà existante. Donc comparer ce type de chaines, consiste à comparer des pointeurs.
Ensuite, pour les autres chaines (qui ne sont pas "internalized" ), calculer le hash nécessite de passer sur la chaine une fois (et une seule car le hash est caché), et si les hash sont égaux, de repasser encore une fois, pour vérifier l'égalité, ce qui est plus lent que de s'arrêter au premier caractère différent entre les 2 chaines.

c'est le mot 'infime' qui m'intéresse. du MD5 avec un fichier de 3go j'ai des doutes que la proba soit infimes.

"des" fichiers de 3 Go
La probabilité pour MD5 est de 1 sur 2^128 (la calculatrice de Ouinedoze me dit 3.4028236692093846346337460743177e+38). Perso, ça me semble largement suffisant ne serait-ce que pour un réseau local, où le total de fichiers sur toutes les machines n'arriverait pas à la cheville de ce chiffre

Hachoir double classique, acier anglais :

La loi de Murphy tu connais ?  

ce nombre
 
par contre, je suis très étonné que Dark ne connaisse rien (ou en tout cas ait de sérieuses lacunes) au hachage, je le croyais plus cultivé que ça.

Alors forcément, si on se base dessus, smal barré

 
  oui bon ok c'est bien.

je sens que ça va dégénérer, donc je plante mon drapeau

ne rien dire, ne rien dire...

ouais, l'aglo spa terrible
vaut mieux du bon vrai chêne massif

stack ta race