Merci de nous livrer ce projet qui correspond à un de mes plus vieux besoins. J'avais pondu un hack un peu similaire en python, il y a quelques années (si vraiment ça intéresse quelqu'un je peux coller le code). Du coup j'aimerais réagir et poser quelques questions à son auteur.
L'idée était de tracer certains fichiers de média pour détecter les doublons mais aussi retrouver ceux qui avaient été déplacés ou même supprimés.
Ceci correspond pas mal à un cas d'utilisation de "fim" et j'avais nommé mon script "déjavu".
Imaginez: Vous disposez d'une collection de médias, ebooks, photos, articles en pdf, films ou rips DVD et vous en consommez pas mal. Le problème est que lorsque vous en récupérez des nouveaux, vous aimeriez connaître ceux que vous avez déjà, ceux que vous avez déjà vu et supprimés ou écartés parce qu'ils ne vous intéressent pas.
Quel meilleur moyen que de hasher tous vos fichiers et de conserver leur trace dans une base ?
Vous récupérez une photo que vous avez déjà vue mais volontairement trashée parce qu'elle était floue. Hop! Son hash est déjà présent et le fichier n'existe plus. C'est donc un fichier "déjà vu". Votre programme ne la recopie pas dans votre collection.
Celle là est déjà présente, ... à la suivante.
Avec fim diff, qui affiche les fichiers supprimés, on a déjà ça.
En partant de cette base, j'avais aussi créé un autre script pour scanner les doublons.
Maintenant, j'aurais quelques questions sur ce projet:
Que fait l'option de purge exactement ?
Pourquoi avoir privilégié le SHA-512 ? Personnellement mon besoin était de disposer d'un algo de hashage qui soit rapide et qui minimise le nombre de collisions. Notamment, il me fallait que la probabilité que 2 fichiers différents avec une même taille et un hash identique soit la plus faible possible. Au début, j'avais opté pour le hashage de fichier du site "opensubtitles" puis j'ai adopté md5. Je croyais que SHA était plus dédié à la cryptographie et moins dédié au contrôle d'intégrité (au sens de la corruption pas du piratage). SHA-512 est-il aussi efficace pour ce besoin ? Connaissez-vous des sites qui permettent de faire des comparaisons ?
Pourquoi historiser tous les changements (fim log) ? Pour mon besoin, je conservais tous les changements depuis le début en un seul état et le comparais à l'état courant (buffer à importer). Quel est l'intérêt pour les cas d'utilisation de fim de conserver le log ?
Concernant les hashs: il y a 3 niveaux de hash. Le complet; le 1 mb et le 4kb. Personnellement je n'avais que 2 niveaux: le complet et le partiel. Mon hash partiel traitait 3 blocs de 4K disjoints dans un fichier: 1 au début, 1 à la fin et 1 au milieu. Ca me permettait de rapidement détecter des fichiers différents sur la totalité. (Genre une série avec le même générique de début, ...). Est-ce que le hash de 1mb est suffisant ?
Pour traiter le cas de fichiers avec une entête différente, (genre un flac avec des tags modifiés) j'ai vu que le hash démarrait à partir d'un certain offset. C'est astucieux. Est-il prévu de traiter à terme des médias en tenant compte de leur type (y compris sur le hash global) ? Par exemple en montrant quand la différence ne porte que sur l'entête.
# 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é à 5.
Merci de nous livrer ce projet qui correspond à un de mes plus vieux besoins. J'avais pondu un hack un peu similaire en python, il y a quelques années (si vraiment ça intéresse quelqu'un je peux coller le code). Du coup j'aimerais réagir et poser quelques questions à son auteur.
L'idée était de tracer certains fichiers de média pour détecter les doublons mais aussi retrouver ceux qui avaient été déplacés ou même supprimés.
Ceci correspond pas mal à un cas d'utilisation de "fim" et j'avais nommé mon script "déjavu".
Imaginez: Vous disposez d'une collection de médias, ebooks, photos, articles en pdf, films ou rips DVD et vous en consommez pas mal. Le problème est que lorsque vous en récupérez des nouveaux, vous aimeriez connaître ceux que vous avez déjà, ceux que vous avez déjà vu et supprimés ou écartés parce qu'ils ne vous intéressent pas.
Quel meilleur moyen que de hasher tous vos fichiers et de conserver leur trace dans une base ?
Vous récupérez une photo que vous avez déjà vue mais volontairement trashée parce qu'elle était floue. Hop! Son hash est déjà présent et le fichier n'existe plus. C'est donc un fichier "déjà vu". Votre programme ne la recopie pas dans votre collection.
Celle là est déjà présente, ... à la suivante.
Avec fim diff, qui affiche les fichiers supprimés, on a déjà ça.
En partant de cette base, j'avais aussi créé un autre script pour scanner les doublons.
Maintenant, j'aurais quelques questions sur ce projet:
Que fait l'option de purge exactement ?
Pourquoi avoir privilégié le SHA-512 ? Personnellement mon besoin était de disposer d'un algo de hashage qui soit rapide et qui minimise le nombre de collisions. Notamment, il me fallait que la probabilité que 2 fichiers différents avec une même taille et un hash identique soit la plus faible possible. Au début, j'avais opté pour le hashage de fichier du site "opensubtitles" puis j'ai adopté md5. Je croyais que SHA était plus dédié à la cryptographie et moins dédié au contrôle d'intégrité (au sens de la corruption pas du piratage). SHA-512 est-il aussi efficace pour ce besoin ? Connaissez-vous des sites qui permettent de faire des comparaisons ?
Pourquoi historiser tous les changements (fim log) ? Pour mon besoin, je conservais tous les changements depuis le début en un seul état et le comparais à l'état courant (buffer à importer). Quel est l'intérêt pour les cas d'utilisation de fim de conserver le log ?
Concernant les hashs: il y a 3 niveaux de hash. Le complet; le 1 mb et le 4kb. Personnellement je n'avais que 2 niveaux: le complet et le partiel. Mon hash partiel traitait 3 blocs de 4K disjoints dans un fichier: 1 au début, 1 à la fin et 1 au milieu. Ca me permettait de rapidement détecter des fichiers différents sur la totalité. (Genre une série avec le même générique de début, ...). Est-ce que le hash de 1mb est suffisant ?
Pour traiter le cas de fichiers avec une entête différente, (genre un flac avec des tags modifiés) j'ai vu que le hash démarrait à partir d'un certain offset. C'est astucieux. Est-il prévu de traiter à terme des médias en tenant compte de leur type (y compris sur le hash global) ? Par exemple en montrant quand la différence ne porte que sur l'entête.