Pour commencer, non, il n'y a pas encore d'interface graphique. Je sais qu'une interface console rebute de plus en plus de monde. C'est dommage, le mode texte a pourtant de nombreux avantages. Sachant que l'aide est quasiment absente, il faudrait que je détaille un peu.
Avant j'aimerais parler d'une des nouveautés d'Hachoir : le support du système de fichiers FAT. Euh... oops on est sur linuxfr.org... Oui, ça fait bizarre. D'ailleurs, ce format ne m'intéresse pas du tout. Mais à défaut d'être bien foutu, il a l'avantage d'être simple et de bien mettre en évidence les limitations d'Hachoir. Sans les améliorations apportées à l'API d'Hachoir, implémenter FAT aurait été presque impossible.
[1] Ce système de fichiers n'a pas une structure arborescente. Tout est à plat et pour atteindre un fichier en particulier, il faudrait presque tout parser et on finirait avec un liste de plusieurs miliers d'entrées. On ne peut plus dire qu'Hachoir reste paresseux ; on serait vite limité à des petits FS.
[2] Admettons qu'on atteigne le champ qui contient les données du fichier recherché. On peut vouloir hacher le contenu. C'était possible avec Hachoir 0.1. Voilà, la feature est de nouveau là, dans l'interface urwid.
[3] Oui mais... quel système de fichiers ne fragmente jamais ? Sûrement pas la FAT.
Hachoir 0.5 marque le début du support des containers.
J'appelle container tout format destiné à contenir des données dans un format quelconque. Les catégories les plus courantes sont :
- archives : C'est le cas le plus facile. Le contenu est en un seul morceau. (La compression est une toute autre histoire)
- systèmes de fichiers : Ca se corce. On fait souvent face à des contenus fragmentés.
- containers multimedia : Là, ça peut devenir un cauchemar. Il s'agit souvent d'un flux de paquets (un paquet pouvant être à son tour fragmenté ; avec 2 types de fragmentation, finir le parseur ogg va être un casse-tête) et le format ne peut pas se contenter d'un flux bêtement défragmenté : il peut avoir besoin de connaître le découpage.
Dans l'interface urwid, 2 raccourcis ont fait leur apparition :
1. La touche 'espace', utile pour les parseurs non terminés. Il considère le champ actuellement sélectionné comme un contenu ayant son propre format. Une nouvelle fenêtre est ouverte, Hachoir cherche un parseur approprié et commence un nouveau hachage. On peut l'utiliser n'importe où et même pour un fichier non fragmenté dans un FS. Actuellement, c'est le seulement moyen d'hacher :
- une partition si on a lancé hachoir sur un disque entier
- un fichier attaché à un fichier matroska
- ...
2. La touche 'f' qui, pour le moment, fonctionne uniquement pour le parseur FAT. Une fois que le début d'un fichier (fragmenté ou non) est sélectionné (il ne faut pas sélectionner le champ "data" mais le champ parent), une nouvelle fenêtre est ouverte et cette fois-ci, c'est tout le contenu défragmenté qui est haché.
Pour ceux qui seraient intéressés par le support des flux fragmentés, un bug sérieux affecte malheureusement la version 0.5. Je m'en suis aperçu quelques heures après que tout a été packagé. Il faudra alors appliquer le patch http://hachoir.org/changeset/726 (plutôt gruik d'ailleurs ; va falloir que je revois l'API) ou télécharger depuis le dépôt subversion.
Une autre nouveauté : le lien interne. Dans urwid, on suit un lien tout comme on développe/réduit un champ : avec la touche 'entrée'. Le lien permet de faciliter là navigation.
Pour l'instant, il y en a très peu : dans les parseurs Matroska et FAT uniquement.
Dans les fichiers Matroska, il existe une structure ('Cues') qui indexe certaines trames. En général, les trames clés d'un flux video. Il faut consulter plusieurs champs pour localiser la trame clé dans le fichier, et de toute façon, même si un seul champ suffisait, celui-ci ne serait pas forcément intelligible : indice de temps, ou position en octets par rapport à un endroit bien précis (et lire les specs pour le connaître), etc.
Dans le cas du système FAT, les liens permettent par exemple de naviguer entre les différents fragments d'un fichier.
Mais c'est surtout en suivant le lien dans une entrée de répertoire qu'on déclenche le hachage du fichier correspondant à cet entrée. Cela résoud [1]. On laisse des zones non hachées (padding) puis on hache ces zones à la demande.
# Compléments
Posté par lcld . En réponse à la dépêche Hachoir, le couteau suisse qui découpe vos fichiers binaires. Évalué à 10.
Avant j'aimerais parler d'une des nouveautés d'Hachoir : le support du système de fichiers FAT. Euh... oops on est sur linuxfr.org... Oui, ça fait bizarre. D'ailleurs, ce format ne m'intéresse pas du tout. Mais à défaut d'être bien foutu, il a l'avantage d'être simple et de bien mettre en évidence les limitations d'Hachoir. Sans les améliorations apportées à l'API d'Hachoir, implémenter FAT aurait été presque impossible.
[1] Ce système de fichiers n'a pas une structure arborescente. Tout est à plat et pour atteindre un fichier en particulier, il faudrait presque tout parser et on finirait avec un liste de plusieurs miliers d'entrées. On ne peut plus dire qu'Hachoir reste paresseux ; on serait vite limité à des petits FS.
[2] Admettons qu'on atteigne le champ qui contient les données du fichier recherché. On peut vouloir hacher le contenu. C'était possible avec Hachoir 0.1. Voilà, la feature est de nouveau là, dans l'interface urwid.
[3] Oui mais... quel système de fichiers ne fragmente jamais ? Sûrement pas la FAT.
Hachoir 0.5 marque le début du support des containers.
J'appelle container tout format destiné à contenir des données dans un format quelconque. Les catégories les plus courantes sont :
- archives : C'est le cas le plus facile. Le contenu est en un seul morceau. (La compression est une toute autre histoire)
- systèmes de fichiers : Ca se corce. On fait souvent face à des contenus fragmentés.
- containers multimedia : Là, ça peut devenir un cauchemar. Il s'agit souvent d'un flux de paquets (un paquet pouvant être à son tour fragmenté ; avec 2 types de fragmentation, finir le parseur ogg va être un casse-tête) et le format ne peut pas se contenter d'un flux bêtement défragmenté : il peut avoir besoin de connaître le découpage.
Dans l'interface urwid, 2 raccourcis ont fait leur apparition :
1. La touche 'espace', utile pour les parseurs non terminés. Il considère le champ actuellement sélectionné comme un contenu ayant son propre format. Une nouvelle fenêtre est ouverte, Hachoir cherche un parseur approprié et commence un nouveau hachage. On peut l'utiliser n'importe où et même pour un fichier non fragmenté dans un FS. Actuellement, c'est le seulement moyen d'hacher :
- une partition si on a lancé hachoir sur un disque entier
- un fichier attaché à un fichier matroska
- ...
2. La touche 'f' qui, pour le moment, fonctionne uniquement pour le parseur FAT. Une fois que le début d'un fichier (fragmenté ou non) est sélectionné (il ne faut pas sélectionner le champ "data" mais le champ parent), une nouvelle fenêtre est ouverte et cette fois-ci, c'est tout le contenu défragmenté qui est haché.
Pour ceux qui seraient intéressés par le support des flux fragmentés, un bug sérieux affecte malheureusement la version 0.5. Je m'en suis aperçu quelques heures après que tout a été packagé. Il faudra alors appliquer le patch http://hachoir.org/changeset/726 (plutôt gruik d'ailleurs ; va falloir que je revois l'API) ou télécharger depuis le dépôt subversion.
Une autre nouveauté : le lien interne. Dans urwid, on suit un lien tout comme on développe/réduit un champ : avec la touche 'entrée'. Le lien permet de faciliter là navigation.
Pour l'instant, il y en a très peu : dans les parseurs Matroska et FAT uniquement.
Dans les fichiers Matroska, il existe une structure ('Cues') qui indexe certaines trames. En général, les trames clés d'un flux video. Il faut consulter plusieurs champs pour localiser la trame clé dans le fichier, et de toute façon, même si un seul champ suffisait, celui-ci ne serait pas forcément intelligible : indice de temps, ou position en octets par rapport à un endroit bien précis (et lire les specs pour le connaître), etc.
Dans le cas du système FAT, les liens permettent par exemple de naviguer entre les différents fragments d'un fichier.
Mais c'est surtout en suivant le lien dans une entrée de répertoire qu'on déclenche le hachage du fichier correspondant à cet entrée. Cela résoud [1]. On laisse des zones non hachées (padding) puis on hache ces zones à la demande.