Merci pour la réponse.
De ce tableau, j'en déduis que MD5 est plus sujet aux collisions et assez médiocre question performance. Je suis surpris mais c'est rassurant.
Autre question.: Si "purge" supprime les états antérieurs, ça signifie qu'il va perdre l'information comme quoi un fichier a été supprimé par le passé, alors que c'est ce qui est intéressant dans mon cas d'utilisation. Je n'ai toujours pas bien saisi ce qu'apportait par rapport à tes besoins une vision intermédiaire de chaque plutôt que globale en agrégeant tout.
Pour le hash de 1mb, lorsque je demandais si ça pouvait suffire, c'est par rapport au fait de différencier des fichiers, pas par rapport aux performances. C'est pour ça que je parlais de blocs séparés.
Pour ce qui concerne les contributions, je soumettrai peut-être quelques feature requests/bugs en fonction de l'usage. Pour le code j'ai jeté un coup d'oeil et c'est plus tôt pas mal (mis à part les commentaires assez chiches ;-). J'arrive presque à comprendre . Java n'est pas trop ma tasse de thé (trop verbeux) mais qui sait ? Accepterais-tu des contributions en Groovy ?
Sinon, j'avais oublié de te dire que le répertoire caché qu'on recopie ou déplace en conservant des chemins relatifs (inspiré des VCS) est astucieux aussi. Mon script conservait une base centralisée qui essayait de tracer les fichiers sur tous les disques montés et en restant indépendant des machines. Du coup j'essayais de conserver un chemin absolu qui concatenait le nom de volume (en NTFS) et le chemin depuis la racine. Mais c'était un vrai casse-tête surtout pour traiter les autres fs. Il faut vraiment que je l'utilise sur mes médias pour te faire un retour complet.
[^] # Re: Trés beau projet.
Posté par El Titi . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 2.
Merci pour la réponse.
De ce tableau, j'en déduis que MD5 est plus sujet aux collisions et assez médiocre question performance. Je suis surpris mais c'est rassurant.
Autre question.: Si "purge" supprime les états antérieurs, ça signifie qu'il va perdre l'information comme quoi un fichier a été supprimé par le passé, alors que c'est ce qui est intéressant dans mon cas d'utilisation. Je n'ai toujours pas bien saisi ce qu'apportait par rapport à tes besoins une vision intermédiaire de chaque plutôt que globale en agrégeant tout.
Pour le hash de 1mb, lorsque je demandais si ça pouvait suffire, c'est par rapport au fait de différencier des fichiers, pas par rapport aux performances. C'est pour ça que je parlais de blocs séparés.
Pour ce qui concerne les contributions, je soumettrai peut-être quelques feature requests/bugs en fonction de l'usage. Pour le code j'ai jeté un coup d'oeil et c'est plus tôt pas mal (mis à part les commentaires assez chiches ;-). J'arrive presque à comprendre . Java n'est pas trop ma tasse de thé (trop verbeux) mais qui sait ? Accepterais-tu des contributions en Groovy ?
Sinon, j'avais oublié de te dire que le répertoire caché qu'on recopie ou déplace en conservant des chemins relatifs (inspiré des VCS) est astucieux aussi. Mon script conservait une base centralisée qui essayait de tracer les fichiers sur tous les disques montés et en restant indépendant des machines. Du coup j'essayais de conserver un chemin absolu qui concatenait le nom de volume (en NTFS) et le chemin depuis la racine. Mais c'était un vrai casse-tête surtout pour traiter les autres fs. Il faut vraiment que je l'utilise sur mes médias pour te faire un retour complet.