Etienne Vrignaud a écrit 26 commentaires

  • [^] # Re: Coquille

    Posté par  . En réponse à la dépêche Optimisations et corrections pour Fim 1.2.3. Évalué à 2.

    Le titre "Les nouveautés depuis la version 1.2.3" devrait être "Les nouveautés depuis la version 1.2.2" sinon c'est pas logique.

  • [^] # Re: Parchive & Reed-Solomon

    Posté par  . En réponse à la dépêche Optimisations et corrections pour Fim 1.2.3. Évalué à 1.

    Ca peut-être une idée d'évolution.
    J'ai ajouté une issue github pour cela. https://github.com/evrignaud/fim/issues/17

  • [^] # Re: Cible?

    Posté par  . En réponse à la dépêche Optimisations et corrections pour Fim 1.2.3. Évalué à 3.

    Il y a une explication plus complète de Fim ici sous forme d'une présentation en français.
    https://evrignaud.github.io/fim/slides/fr.html#/fim

  • [^] # Re: Cible?

    Posté par  . En réponse à la dépêche Optimisations et corrections pour Fim 1.2.3. Évalué à 3.

    Fim permet de dédupliquer les fichiers, mais ca n'est pas son utilisation première.
    Il ne permet pas de gérer les fichiers de la même manière que Dolphin le fait.

    Le but de Fim est de pouvoir gérer un espace de travail pour 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. Cela se fait très rapidement.

  • [^] # Re: Attention à la dé-duplication

    Posté par  . En réponse à la dépêche Optimisations et corrections pour Fim 1.2.3. Évalué à 2.

    En effet c'est un bon point dans Fim on compare uniquement les hash.
    J'ai ajouté une issue dans Github pour comparer aussi la taille de fichiers. https://github.com/evrignaud/fim/issues/16
    Dans tous les cas on a le choix, soit on hash 3 blocks ou on hash tout le contenu.
    Le risque de collision est très faible grâce a l'algorithm de hash SHA-512 qui est utilisé.

  • [^] # Re: Effacement des doublons

    Posté par  . En réponse à la dépêche Effacement des doublons et historique complet pour Fim 1.2.2. Évalué à 5.

    C'est une très bonne idée pour la prochaine version j'ajouterais une option pour créer des hard link plutôt que d'effacer les fichiers.

  • [^] # Re: NIH et autres considérations

    Posté par  . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 2.

    L'indication "JAVA_OPTIONS="-Xmx4g -XX:MaxMetaspaceSize=4g" est juste un maximum d'allocation mémoire pour la JVM.
    Fim dans une utilisation "normale" utilise moins de ram.
    Voici des chiffres que j'ai collectés sur une utilisation de Fim avec 348 344 fichiers.
    Lors de la création du repository Fim a besoin de 1,9 GB de Heap et 13 MB de Metaspace.
    Pour les utilisations suivantes pour comparer l'état actuel avec le précédent il a besoin de 2,5 GB de Heap et toujours 13 MB de Metaspace.
    Durant l'execution de Fim le State complet est chargé en mémoire et donc quand on fait des comparaisons de State, les deux sont chargés en mémoire. C'est cela qui charge beaucoup la ram.

    Peut-être que certains aspects dans Fim peuvent améliorés. N'oublions pas que Fim est juste en version 1.
    Il est toujours possible d'exprimer des besoins afin que j'étudie une piste d'optimisation, suivant les problèmes rencontrés.
    Ou alors de contribuer par des pull request.

  • [^] # Re: Gérer les fichiers

    Posté par  . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 1.

    En gros, c'est ce que fait le mode 'do not hash' de fim quand on utilise l'option -n

  • [^] # Re: Gérer les fichiers

    Posté par  . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 4.

    Comme vous le faites très justement remarquer, Fim réalise des opération assez basiques. Il permet de faire un index des hash des fichiers d'une arborescence.
    Ce qui est interessant avec Fim c'est qu'il fourni des commandes pour utiliser à bon escient ces hash.
    Fim se caratérise par les fonctionnalités suivantes:
    - Le mode super-fast permet de réaliser diverses opérations très rapidement en évitant de hasher tout le contenu fichiers ce qui accélère énormément les opérations.
    - La comparaison du State courant avec le State précédent permet d'obtenir des informations intéressantes comme les modification, ajout, suppression, renommage.
    - La détection rapide des fichiers dupliqués.

    Tout cela est diffile a réaliser avec des script qui font du hashage brutal de tous les fichiers d'un répertoire.
    Et cela ne sera pas performant.

    Concernant les fonctionnalités avancées qui semblent manquer, je ne suis pas sûre que cela soit destiné à Fim.
    Fim à été créé pour être un outil simple d'utilisation. Pour une utilisation avec plusieurs dépots ou autre, il vaut mieux passer à des outils comme git-lfs (https://git-lfs.github.com/) ou git-annex (https://git-annex.branchable.com/).

  • [^] # Re: Binaire ?

    Posté par  . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 4.

    C'est une bonne remarque. Mais le format de stockage des State n'est pas du binaire.
    C'est du json compressé avec un algo gzip.
    Et donc pour produire du json valide il faut convertir le binaire résultant du hachage en chaine de caractère.
    J'ai trouvé que c'était la façon la plus simple de stocker les informations du State et la façon la plus évolutive.
    En effet, il est possible d'ajouter autant d'attribut que l'on veut à un State, pas de problèmes du type taille de record ou autre.

  • [^] # Re: Paquet binaire

    Posté par  . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 1.

    C'est une chose que je n'ai pas encore étudiée.
    Je pense qu'il serait intéressant de distribuer Fim sous forme de Snap, le nouveau type de packaging qui vient avec Ubuntu 16.04.
    Sinon les contributions pour réaliser des packaging du type .deb ou .rpm sont les bien venues.

  • [^] # Re: Liens symboliques ?

    Posté par  . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 2.

    Fim supporte très bien les liens symboliques. Il les ignore.

  • [^] # Re: fichier en erreur ?

    Posté par  . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 2.

    Il existe la commande fim --detect-corruption qui peut t'aider. Mais elle ne propose pas d'effacer les fichiers corrompus. Peut-être que ca pourrais être pratique. Et donc tu aurais plus qu'a merger les répertoires contenant des archives.
    Mais ca c'est la cas idéal où tous les contenus sont identiques.
    Si les contenus des fichiers ont évolués ou qu'ils été renommés depuis les copies, c'est pas simple de merger.

  • [^] # Re: Il existe aussi Git-Annex

    Posté par  . En réponse à la dépêche Fim 1.1.0. Évalué à 2.

    Les deux outils (annex, git-lfs) semblent intéressant. J'ai essayé les deux. Je dirais même que lfs est vraiment très bien.
    Mais ils semblent répondre à des cas d'utilisation très poussés avec un remote.
    Fim à été créé pour être super simple mais puissant en même temps.
    Le hashage des fichiers est réalisé avec plusieurs thread en parallèle.
    Et on a facilement un status clair des fichiers renommé, déplacé ou dupliqués ce que je n'ai pas réussi à avoir simplement avec annex ou lfs.
    De plus Fim à la mode super fast.

  • [^] # Re: ceci n'est pas une cabale

    Posté par  . En réponse à la dépêche Fim 1.1.0. Évalué à 1.

    Oui en effet, c'est la préoccupation du moment.
    De plus en plus de choses sont dématérialisées (photos, vidéos, papiers en pdf).
    Il est important de savoir où ils sont et dans quel état.
    Fim est là pour gérer tout type de contenu dématérialisé.

  • [^] # Re: Des S

    Posté par  . En réponse à la dépêche Fim 1.1.0. Évalué à 2.

    Merci pour les retours sur la Typo. J'apprécie.
    J'y fixe au plus tôt.

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

    Posté par  . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. É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  . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. É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é.

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

    Posté par  . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 1.

    Oui, ouvre un ticket pour ca.

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

    Posté par  . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. É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  . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. É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  . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. É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: Système de fichiers ?

    Posté par  . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 1.

    J'ai répondu après aux deux commentaires qui me paraissent similaire.

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

    Posté par  . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. É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: Possible lien avec Inotify

    Posté par  . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. É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.