Fim (File Integrity Manager) sort dans sa version 1.2.3 avec diverses corrections.
Fim est un gestionnaire de fichiers libre (licence GPL v3) qui permet de gérer de nombreux fichiers de n’importe quelle taille. Il peut, par exemple, gérer des musiques, 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 les effacer.
Les nouveautés de la version 1.2.3
Général
- passage de Gson à Jackson pour avoir un sérialiseur plus efficace ;
- réduction de la quantité de mémoire nécessaire pour charger un State.
Corrections de bogues
- correction du problème no 9 : Exception dans le fil d’exécution « principal » java.lang.IllegalStateException ;
- correction de l’algorithme de comparaison d’état ;
- lorsque la taille dépasse 1 Go, Fim n’arrondit plus au Go le plus proche ;
- utilisation du système international d’unités (SI) pour calculer la taille d’un fichier (1 000 — kilo — au lieu de 1 024 — kibi).
Aller plus loin
- Journal des modifications (191 clics)
- Documentation (293 clics)
- Page GitHub du projet (628 clics)
- Dépêche précédente : Effacement des doublons et historique complet pour Fim 1.2.2 (200 clics)
# Coquille
Posté par ylsul . Évalué à 2.
"Fim n'arrondi plus" -> "n'arrondit"
[^] # Re: Coquille
Posté par ZeroHeure . Évalué à 2.
Corrigé, merci
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Coquille
Posté par Etienne Vrignaud . É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: Coquille
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
Corrigé, merci.
# Cible?
Posté par ʭ ☯ . Évalué à 3.
Tout gestionnaire de fichiers ayant vocation à faire ce qui est décrit : "permet de gérer de nombreux fichiers", je suppose que c'est plus qu'un Dolphin avec fdupes intégré?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Cible?
Posté par gUI (Mastodon) . Évalué à 5.
Oui, on pourrait avoir quelques éclaircissements sur le terme "gérer" ? Merci :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Cible?
Posté par Etienne Vrignaud . É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: Cible?
Posté par Etienne Vrignaud . É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
# Attention à la dé-duplication
Posté par zyphos . Évalué à 5.
Dans le code, uniquement les hashes sont utilisés pour détecter les fichiers dupliqués.
Or on sait très bien que les hashes ont des collisions, elles sont rares, mais elles existent. (Forcément, sinon pourquoi perdrait-on des milliers de Mo pour stocker des fichiers alors que quelques octets (les hashes) suffisent…)
Pour trouver des fichiers dupliqués voici une approche:
1. On vérifie les tailles (c'est la plus rapide vérification)
2. Si les tailles sont identiques, on vérifie les hashes (complet sur les fichiers) (on stock les hashes pour ne pas les recalculer à chaque fois)
3. Si les hashes sont identiques, on compare les contenus en entier.
J'ai déjà eu des dizaines de fichiers effacés par erreur par un outil qui faisait de la dé-duplication. Liten (https://code.google.com/archive/p/liten/), il y a un également Liten2 (https://code.google.com/archive/p/liten2/) Tous les 2 sont à proscrire. Ils utilisent (enfin utilisaient, je n'ai plus regardé le code source) un hash basé sur les premiers 16Ko des fichiers. Pour aller plus vite…
[^] # Re: Attention à la dé-duplication
Posté par shbrol . Évalué à 2.
Autre approche :
1. On vérifie les tailles
2. On vérifie les hash partiels (N Ko au début + à la fin)
3. On verifie les hash complets (sans les stocker)
4. On compare le contenu en entier.
Evidemment, si tu t'arrête à 2), tu va avoir des problèmes.
Mais est-ce vraiment nécessaire de faire 4) après 3) ?
[^] # Re: Attention à la dé-duplication
Posté par Etienne Vrignaud . É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: Attention à la dé-duplication
Posté par steph1978 . Évalué à 2.
Donc c'est surtout un bug.
Un hash sur le début du fichier peut être un hint - si on a pas ce hash on est sûr que le fichier est non connu.
Mais si ce hash est connu, il faut poursuivre sur le contenu complet. C'est ce que fait FIM si je me rappelle mes lectures.
Si tu prends taille + hash complet, le risque de collision est infinitésimal.
# Parchive & Reed-Solomon
Posté par paipai62 . Évalué à 1.
Bonjour,
Dans un des use-case on imagine,
que je détecte une corruption matérielle avec « fim dcor »
Je fais quoi après ?
Pense-tu dans le future implémenter un système à la par2 (lui même vérifiable) ?
[^] # Re: Parchive & Reed-Solomon
Posté par Etienne Vrignaud . É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
# Hardlink ou symlink à la place de la suppression ?
Posté par showtime . Évalué à 1.
Pour la gestion de mes photos et vidéos, ainsi que de mes papiers, j'utilise fdupes ou fslint, mais je les trouve largement imparfaits. Fim pourrait donc être une alternative correcte. Cependant, il manque une fonctionnalité qui me semble essentielle: celle de remplacer un doublon par un hardlink ou un symlink (sous Linux) et éventuellement un raccourci (sous Windows).
Je vois également un autre cas d'usage de Fim, qui n'est pas cité explicitement dans la doc: celui de la vérification des fichiers de tout ton système, un peu à la manière de Tripwire.
# nom peut-être mal choisi
Posté par Plinn . Évalué à 2.
Au départ ça m'a fait tiquer car pour moi FIM c'est un soft de manipulation d'image présent dans toutes les distributions depuis un moment déjà:
FIM
Vu qu'on fait généralement : apt install fim
Comment celui-ci va-t-il s'appeler? la confusion est inévitable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.