Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers

Posté par  . Édité par Benoît Sibaud et Pierre Jarillon. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
44
8
sept.
2015
Ligne de commande

Fim (File Integrity Manager) est un gestionnaire de fichiers libre (licence GPLv3) qui permet de gérer beaucoup de fichiers de n'importe quelle taille. Il peut par exemple, gérer des photos ou des vidéos. Il est capable de gérer des centaines de milliers de fichiers occupant une taille totale de plusieurs téraoctets. Il peut détecter les fichiers dupliqués et aider à les effacer.

Fim

Fim est un outil ligne de commande qui permet de gérer les fichiers avec un esprit qui ressemble à Git.
Il est différent de Git car il ne conserve pas le contenu des différentes versions des fichiers.
Vous ne pouvez pas utiliser Fim pour retrouver un contenu que vous auriez perdu.

Fim conserve dans le répertoire .fim un état de chaque fichier dans des index qui contiennent :

  • Le nom, la taille et la date de modification du fichier
  • 3 hash du contenu (hash du contenu complet, hash du deuxième bloc de 1 MB, hash du deuxième bloc de 4 KB)

Les deux hash supplémentaires qui sont calculés sont utilisés lors des comparaisons rapides.

Voici les commandes disponibles dans Fim:

  • init : initialise le répertoire .fim et crée le premier index contenant l'état des fichiers,
  • ci ou commit : crée un nouvel index contenant l'état actuel des fichiers,
  • diff : permet de savoir quel fichier a été ajouté, modifié, effacé, déplacé, renommé, dupliqué. On peut avoir un résultat rapide en utilisant les options -m ou -k ou -f ,
  • log : affiche l'historique des différents index et un résumé des modifications qui ont été apportées,
  • fdup ou find-duplicates : affiche la liste des fichiers dupliqués.

Aller plus loin

  • # Système de fichiers ?

    Posté par  (site web personnel) . Évalué à 2.

    Fim (File Integrity Manager) est un gestionnaire de fichiers libre (…)

    En lisant cette phrase, j'ai eu l'impression qu'ils ne gère que les fichiers libres, mais pas les autres (malgré l'absence de s). J'aurais tourné ça en « gestionnaire libre de fichiers ».

    En ce qui concerne la gestion de l'intégrité des fichiers, c'est un peu le boulot du système de fichiers, non ?

    Ici, c'est juste une sorte de dépôt de quelques sommes de contrôles des fichiers.

    Concernant son usage, j'en comprends le but, mais je ne suis pas certain de trouver un cas dans lequel je l'utiliserais. Par contre, un outil me disant qui a modifié tel fichier et quand, là je serai bien content :)

    • [^] # Re: Système de fichiers ?

      Posté par  (site web personnel) . Évalué à 3.

      En ce qui concerne la gestion de l'intégrité des fichiers, c'est un peu le boulot du système de fichiers, non ?

      Hum oui, sauf qu'il n'y en a que peu qui supportent cette fonctionnalité. Btrfs peut stocker un hash et plusieurs versions d'un fichier. En cas d'erreur, on peut récupérer une vieille version du fichier. ZFS sait aussi stocker le hash d'un fichier.

      ext4 et XFS ne savent pas stocker le hash d'un fichier par exemple.

      Pour moi la question est plutôt d'être avertit quand un fichier est corrompu. Je vois mal Btrfs envoyer un rapport par email ou l'afficher dans une interface graphique.

      Note: depuis récemment, ext4 supporte le checksum sur les métadonnées des fichiers, mais pas sur leur contenu.

      • [^] # Re: Système de fichiers ?

        Posté par  . Évalué à 9.

        Il est vrai que c'est le rôle du système de fichiers de vérifier l'intégrité des fichiers.
        Mais Fim n'est pas là pour le remplacer.

        Le but de Fim est de pouvoir gérer un espace de travail.
        Et de savoir où on en est dans les modifications que l'on est en train de faire.
        Quand on fait plein de truc en même temps, les choses prennent du temps et on en perd le fil.

        Personnellement j'utilise Fim pour gérer mes photos et mes vidéos.
        Quand j'ai des nouvelles photos, je les poses au bon endroit dans mon répertoire de photos et ensuite je fais fim ci depuis le sous répertoire qui contient les nouvelles photos pour enregistrer ce nouvel état. Comme j'aurais fait avec Git.
        Comme je fais cela depuis un sous répertoire le commit est super rapide car Fim ne hash que les nouveaux fichiers que j'ai ajouté et il ajoute les nouveaux hash a la liste des anciens.

        La commande fim diff me permet de savoir quand je le veux (super rapidement même) si quelque-chose à évolué dans mon répertoire de photos.

        Je peux repérer et effacer facilement les photos que j'aurais dupliquées ailleurs sur mon disque ou sur d'autre ordi avec la commande fim rdup. Pour cela il faut juste que je recopie le répertoire .fim sur l'autre ordi. C'est super rapide.

        • [^] # Re: Système de fichiers ?

          Posté par  (site web personnel) . Évalué à 2.

          Est-ce qu'il gère les fichiers corrompus ?

          J'ai ce problème avec des photos, sauvegarder sur disques dures ou DVD. J'ai souvent plusieurs copy avec la date, mais je sais que sur certaines copies des images sont cassées (un viewer retourne une erreur de lecture de fichier). Est-ce qu'il serait possible de détecter les copies cassées et de retrouver les copies en bonne état ? (même nom, même taille annoncé ? voir même date de création)

          "La première sécurité est la liberté"

      • [^] # Re: Système de fichiers ?

        Posté par  . Évalué à 2.

        Faudrait une API du VFS de l'OS sur laquelle les bureaux, dbus et autres loggers pourraient se brancher pour qu'une interface un peu plus haut niveau puisse présenter l'information à l'utilisateur/admin non ?

  • # tripwire

    Posté par  . Évalué à 2. Dernière modification le 09 septembre 2015 à 10:18.

    Outre la gestion des duplications de fichiers, quelles seraient les différences par rapport à un outil comme tripwire ?

    • [^] # Re: tripwire

      Posté par  . Évalué à 2.

      tripwire c'est plus la gestion des accès et là on est dans la gestion d'intégrité et la recherche rapide de doublons, non ?

      Pour moi, c'est plus complémentaire qu'en opposition.

      • [^] # Re: tripwire

        Posté par  . Évalué à 4. Dernière modification le 10 septembre 2015 à 11:21.

        tripwire c'est plus la gestion des accès

        Euh tripwire, son but c'est de mesurer l'intégrité de fichiers systèmes pour détecter leur modification en dehors d'un process normal de mise à jour système et de péter des alertes (think: worm, rootkit).

        C'est pas du tout fait pour l'utilisateur final et encore moins pour gérer des doublons.
        Ou alors, ça a beaucoup changé depuis que je l'ai utilisé.

  • # Possible lien avec Inotify

    Posté par  (site web personnel) . Évalué à 2.

    Il me semble qu'Inotify du noyau Linux permet d'être attentif à tout changement sur des fichiers / répertoires, mais ce n'est pas résistant au redémarrage.

    Y a-t-il une possibilité d'utilisation d'Inotify par Fim ? Pourquoi ça n'a pas été considéré ?

    • [^] # Re: Possible lien avec Inotify

      Posté par  . Évalué à 4.

      En effet, inotify est vraiment intéressant comme mécanisme.
      Il n'est pas utilisé dans Fim, car Fim est un outil éphémère qui ne tourne que le temps de la commande lancée.
      Il n'y a pas de processus serveur qui surveille en permanence.

    • [^] # Re: Possible lien avec Inotify

      Posté par  . Évalué à 3.

      Ma maigre expérience avec inotify me dit que inotify n'est pas vraiment utilisable avec plusieurs millions de fichiers.

      Je pense que c'est aussi lourd de calculer les sommes que de mettre inotify en place dans un tel cas s'il y a une majorité de petits fichiers.

      • [^] # Re: Possible lien avec Inotify

        Posté par  . Évalué à 3.

        T'a un disque qui traite plusieurs millions d'écritures à la secondes ?
        Perso je n'ai pas eu de problème particulier avec inotify à partir du moment où le thread/process qui traite les événements n'est pas celui qui gère la boucle.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Possible lien avec Inotify

          Posté par  . Évalué à 3. Dernière modification le 11 septembre 2015 à 09:48.

          On peut avoir des millions de fichiers mais que quelques écritures par jour.

          Pour l'utilisabilité, même inotify le dit sur un grand nombre de fichier. Il faut de plus, régler des variables systèmes avant.

          $ inotifywait -r /
Setting up watches.  Beware: since -r was given, this may take a while!

        • [^] # Re: Possible lien avec Inotify

          Posté par  . Évalué à 2.

          T'a un disque qui traite plusieurs millions d'écritures à la secondes ?

          Pas encore mis la main dessus mais avec les derniers NVMe on va finir par passer la barre. Bon tu me diras que sur ce type de workload, inotify… :)

          Si ajoutes l'Omni Path qui arrive, on va pouvoir rechanger la façon de designer les systèmes alors que la plupart des gens n'ont pas encore compris les différences entre un HDD et un SSD.

          • [^] # Re: Possible lien avec Inotify

            Posté par  . Évalué à 2.

            Tu voudrais pas nous en dire plus pour les benêts de mon espèce qui ne voient pas grande différence entre SSD et HDD ?

            La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

            • [^] # Re: Possible lien avec Inotify

              Posté par  . Évalué à 2. Dernière modification le 11 septembre 2015 à 16:21.

              La différence de performance, et au niveau matériel (pas de disque, aucune partie mécanique, …), et dans la manière d'en prendre soin (surtout pas de défragmentation, faire attention à l'alignement des partitions, tous les systèmes de fichiers ne se valent pas pour la durée de vie du SSD, il faut s'occuper de "discarder" les blocks soit avec l'option de montage discard soit avec fstrim selon les modèles, etc…), est pourtant énorme…

              Sans compter la différence de prix, ou le fait qu'un SSD ne peut être que totalement silencieux comparé à un HDD…

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Possible lien avec Inotify

              Posté par  . Évalué à 5.

              Chacun à des propriétés très différentes.

              Un HDD c'est grosso modo un tourne disque. C'est efficace pour faire de la lecture séquentielle (~100Mo/s) et ça coute pas cher, mais si tu veux accéder un endroit précis ça dans les 10ms ce qui est une éternité (cf Latency Numbers Every Programmer Should Know

              Un SDD c'est grosso modo de la RAM. Ça va pas beaucoup plus vite qu'un HDD si tu lis séquentiellement mais tu peux accéder un endroit précis en ~100us.

              Ce genre de propriétés est fondamentale quand tu conçois un système. Sur un HDD tu vas chercher à toujours lire et écrire séquentiellement pour ne pas faire bouger les têtes. Même si ça implique de lire beaucoup trop de donnée c'est toujours plus rapide (c'est par exemple aussi vrai pour la RAM non pas du a un facteur mécanique mais au prefetch).

              Tu as ce genre de décision à prendre partout. Les choix de design sont dirigées par le fonctionnement du matériel (CPU, mémoire, disque, réseau) et des systèmes d'exploitation. Si j'ai un interconnect à 5ns pour pas cher, ça coute peut être moins cher de dédier une machine bourrée de RAM pour faire un cache qui va être attaqué par X machines que de faire le cache sur les machines directement. De même si j'ai un très disque rapide en accès aléatoire peut être qu'un gros mmap va devenir plus efficace qu'un LRU avec éviction qui va demander de recalculer la valeur plus tard etc.

              Si tu ignores ça, tu conçois des trucs qui tournent des ordres de grandeurs plus lentement que ce que permet le matériel. C'est pour ça qu'il est important de comprendre les fonctionnements de ce qu'on utilise et de connaitre par cœur les ordres de grandeur. Sinon c'est impossible de designer quoi que ce soit, ni de faire des dimensionnement au dos de l'enveloppe.

              PS: Oui j'ai beaucoup beaucoup simplifié

      • [^] # Re: Possible lien avec Inotify

        Posté par  (site web personnel) . Évalué à 2.

        Tu peux le faire via lsyncd, tu met une tempo à 5min par exemple donc il traite en léger décaler, puis tu lances ton programme via ionice et nice. Ainsi, la charge est quasi-invisible.

  • # Détecter les problèmes matériels

    Posté par  (site web personnel) . Évalué à 3.

    En voyant le titre, je pensais avoir un moyen simple de répondre à la question « est-ce qu'il y a un fichier qui a changé alors qu'il n'était pas censé ? » i.e. « est-ce que mon disque dur est en train de rendre l'âme et que le contenu des fichiers change tout seul ».

    Si je comprends bien, ce qui s'en rapproche le plus est « fim diff », mais ça liste tous les fichiers qui ont changé, y compris ceux que l'utilisateur a effectivement modifié.

    Est-ce qu'il y a un moyen simple de lister les fichiers pour lesquels les timestamps n'ont pas bougé depuis le dernier commit, mais dont le contenu a changé ? En gros, "btrfs scrub" mais en espace utilisateur.

    (Je pensais être à l'abri des corruptions de données jusqu'au jour où j'ai comparé le contenu d'un backup sur un vieux disque dur avec les données live : 3 corruptions silencieuses en moins de 10 ans sur quelques dizaines de Go de données. Quand même …)

    • [^] # Re: Détecter les problèmes matériels

      Posté par  . Évalué à 3.

      Je pense qu'il y a un autre commentaire qui est similaire

      Est-ce qu'il gère les fichiers corrompus ?

      J'ai ce problème avec des photos, sauvegarder sur disques dures ou DVD. J'ai souvent plusieurs copy avec la date, mais je sais que sur certaines copies des images sont cassées (un viewer retourne une erreur de lecture de fichier). Est-ce qu'il serait possible de détecter les copies cassées et de retrouver les copies en bonne état ? (même nom, même taille annoncé ? voir même date de création)

      Je pense que pour faire cela il faut ajouter un filtre sur les résultats affichés par Fim.
      Pourriez vous créer une issue sur le projet Github de Fim pour expliquer cette demande.
      Merci.

    • [^] # Re: Détecter les problèmes matériels

      Posté par  . Évalué à 3.

      Il y a un autre programme qui correspond parfaitement à votre besoin. Cshatag.
      https://github.com/rfjakob/cshatag
      Il ajoute un hash dans les attributs étendus du fichier ainsi qu'un timestamp. Si le hash change sans un changement de timestamp (modified time), le fichier est considéré comme corrompu. A utiliser avec find et un coup de grep pour n'être informé que du statut .

      L'usage des attributs étendu est très avantageux, si vous copiez ou déplacez le fichier ailleurs, ou voulez tester son intégrité sous un autre compte utilisateur, aucun problème, le hash se déplace avec de façon transparente. C'est bien mieux qu'un index.

  • # Trés beau projet.

    Posté par  . É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.

    • [^] # Re: Trés beau projet.

      Posté par  . Évalué à 3. Dernière modification le 11 septembre 2015 à 08:53.

      Et sinon tu peux mettre à jour ton wiki, la procédure d'install fonctionne pour Mac:

      ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install maven
cd
mkdir git
cd git 
git clone https://github.com/evrignaud/fim.git
cd fim/
/usr/local/bin/mvn clean install
./fim

      • [^] # Re: Trés beau projet.

        Posté par  . Évalué à 1.

        Cette procédure est intéressante pour builder un SNAPSHOT de Fim. Je l'ai ajoutée ici http://evrignaud.github.io/fim/#step-by-step-procedure
        Je tiens toutefois à préciser que Fim est livré avec des release prébuildé qui sont versionnées.
        Je recommande d'utiliser ces release car elles sont ok pour être utilisées
        Quand on fait un clone du master de Fim, on récupère un SNAPSHOT et là il n'y a aucune garantie que ca fonctionne correctement.

        • [^] # Re: Trés beau projet.

          Posté par  . Évalué à 2.

          Les release sont simplement des zips de commits taggés, non ?
          A la limite on peut rajouter de checkouter le dernier tag stable.
          Sinon je peux aussi tester avec un de tes bundles et modifier la procédure.

          PS: Inutile de mettre mon nom, c'est gentil, mais je ne te réclamerai pas de droits d'auteurs (Tu ne t'en sortiras jamais sinon). Si tu ne veux pas apposer ta propre garantie, mets simplement que c'est testé par des contributeurs.

          • [^] # Re: Trés beau projet.

            Posté par  . Évalué à 2.

            Non les release ne sont pas un simple zip des commits taggés.
            Les release contiennent un jar de Fim qui inclus les versions compilées des classes et les classes des dépendances utilisées.
            Elle inclus aussi, un clone du site de doc et les sources de Fim.

        • [^] # Re: Trés beau projet.

          Posté par  . Évalué à 2. Dernière modification le 11 septembre 2015 à 23:45.

          Sinon je peux t'ouvrir un ticket mais chaque à commande que j'invoque, j'ai toujours de message au début,même si ça fonctionne:

          readlink: illegal option -- f
usage: readlink [-n] [file ...]
2015/09/11 23:40:06 - Error - You must specify the command to run

          Si j'ai du temps j'essaierai de déboguer sous Eclipse.

          • [^] # Re: Trés beau projet.

            Posté par  . Évalué à 1.

            Oui, ouvre un ticket pour ca.

            • [^] # Re: Trés beau projet.

              Posté par  . Évalué à 2.

              Inutile, j'ai trouvé d'où venait le problème. Sous Mac readlink version Gnu n'est pas la version par défaut: Il faut donc installer coreutils
              C'est expliqué ici:
              http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnus-readlink-f-on-a-mac

              Du coup, il faut rajouter la ligne suivante dans la procédure d'install:

              brew install coreutils

              et editer le shell fim en remplaçant par greadline.
              Il doit y avoir une autre solution plus propre (fournir une autre shell pour mac ou jouer avec le path et un symlink, …) mais je ne suis pas assez fortiche pour faire des recommandations.

              J'ai testé sur un de mes dirs et ça marche nickel.

              • [^] # Re: Trés beau projet.

                Posté par  . Évalué à 1.

                Est-ce que tu pourrais soit ouvrir une issue Github avec le contenu exact du script, soit faire une pool request avec le script ?
                Merci.

    • [^] # Re: Trés beau projet.

      Posté par  . Évalué à 2.

      Que fait l'option de purge exactement ?
      Elle efface tous les anciens State et ne conserve que le dernier qu'elle renomme state_1.

      Pourquoi avoir privilégié le SHA-512 ?
      Les algorithmes du type SHA2 sont des algorithme de hashage au même titre que MD5 et SHA1 comme indiqué ici: https://fr.wikipedia.org/wiki/SHA-2
      J'ai choisi le SHA-512 pour obtenir un minimum de collision. On peut voire ici que le MD5 est déconseillé. https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions
      Et de plus, ce qui est lent ca n'est pas l'algorithme de hash, c'est la lecture des données sur le disque.
      Par exemple, avec un Core i5 si je ne lit pas les données depuis le disque je peux hasher 3 GB en 47 secondes avec un seul core.
      La même chose en MD5 me donne 3 GB hashé en 24 secondes. Ok, le SHA-512 en deux fois plus lent mais je ne pense pas que ca soit l'algo de hash qui ralentisse le plus dans le cas de Fim. C'est le disque.

      En conclusion, j'ai choisi SHA-512 pour la longueur de sa clé (512 bits) qui permet de diminuer les chances de collision quand on hash des fichiers énormes.

      Pourquoi historiser tous les changements (fim log) ?
      C'est pour pouvoir retrouver ce que l'on a fait comme différentes modifications pour arriver dans cet état.
      On n'a pas les anciens contenus et on ne peut pas comparer, mais on a pour chaque révision le commentaire de commit et un résumé des modifications qui ont été apportées.
      Le fait de conserver les State entiers permet de revenir à l'état d'avant en effaçant simplement le dernier State. Il faudrait que j'ajoute la commande revert pour faire cela.
      Si l'historique gêne, on peut l'effacer avec la commande purge.

      Est-ce que le hash de 1mb est suffisant ?
      En effet, il pourrait suffire. Mais quand on a énormément de fichiers et un très gros volume, le hash de 4kb permet d'avoir un résultat au diff vraiment très rapide.
      Actuellement, je n'ai pas assez d'expérience pour savoir lequel des deux est le plus pertinent.
      C'est une bonne idée de hasher un 1mb en prenant 3 blocs de 4K disjoints dans un fichier: 1 au début, 1 à la fin et 1 au milieu.

      Est-il prévu de traiter à terme des médias en tenant compte de leur type ?
      Je n'ai rien prévu de tel. Mais en effet Fim pourrait évoluer avec le temps.
      Toute bonne idée est la bien venue et les contributions aussi.

      • [^] # Re: Trés beau projet.

        Posté par  . É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.

        • [^] # Re: Trés beau projet.

          Posté par  . Évalué à 2.

          Il y a peut-être encore des choses faire mûrir dans Fim :=)

          J'ai pour habitude d'utiliser beaucoup de méthodes que je nomme au mieux et d'éviter de mettre un commentaire qui répète ce que signifie le nom de la méthode.
          En effet:

          "Code never lies, comments sometimes do."
          -- Ron Jeffries

          Pour que les algos restent clair, j'utilise pas mal le pattern Compose Method décrit par Martin Fowler.

          Les contributions en Goovy sont bien venues aussi.
          Mais pour les parties de Fim qui ont besoin de performance, le java devrait être préféré.

  • # Quelques similarités avec FSLINT.

    Posté par  . Évalué à 2.

    Bonjour,

    Je tenais juste à parler du logiciel FSLINT qui rejoint FIM sur quelques points et qui serait susceptible d'intéresser des utilisateurs.

    Bonne journée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.