Publication de « File Filesystem », un système de fichiers pour fichiers (2021)

 (mgree.github.io)
1 points par GN⁺ 2024-05-02 | 1 commentaires | Partager sur WhatsApp
  • ffs (file filesystem) est un outil qui monte des données semi-structurées comme JSON, YAML ou TOML sous forme de système de fichiers, afin de les parcourir et les modifier avec les outils du shell Unix
  • Le shell Unix dispose de nombreux outils de traitement de chaînes, mais comme sa structure de données de base est le système de fichiers, il n’est pas vraiment adapté à la modification de données arborescentes
  • ffs [file] associe un fichier à un point de montage et, lors du démontage, exporte le résultat mis à jour vers stdout ou vers un fichier de sortie spécifié
  • L’écriture de fichiers et la création de répertoires sont converties en clés et objets JSON ; 1, true, false et un fichier vide sont respectivement reflétés comme nombre, booléens et valeur null
  • Sous Linux, FUSE est nécessaire ; sous macOS, macFUSE est requis. L’outil peut ne pas convenir à Windows, aux environnements où FUSE n’est pas disponible, aux tâches limitées à la recherche ou aux très gros fichiers

Traiter des données semi-structurées comme des répertoires

  • ffs, abréviation de file filesystem, permet de monter des données semi-structurées comme un système de fichiers pour travailler dessus avec des outils shell familiers
  • Les formats actuellement pris en charge sont JSON, YAML, TOML ; la prise en charge d’autres formats est prévue
  • La documentation détaillée est disponible dans la manpage de ffs

Flux de montage et de modification

  • L’exécution par défaut est ffs [file] : elle monte file.blah sur le point de montage file et écrit la version finale mise à jour sur stdout
  • ffs -m MOUNT file permet de spécifier explicitement un point de montage, et -o OUTPUT de définir un fichier de sortie
  • ffs -i file modifie le fichier sur place ; lorsque le volume est démonté, le résultat est réécrit dans file

  • Règles de conversion visibles dans l’exemple

    • echo Mikey Indiana >object/name modifie la valeur JSON name
    • echo 1 >object/nose est reflété comme le nombre 1, et non comme une chaîne
    • mkdir object/pockets et les fichiers qu’il contient sont convertis en objet JSON
    • Le fichier vide mistakes est enregistré comme null dans JSON

Conditions d’installation et distribution

  • Sous Linux, FUSE est nécessaire
  • Sous macOS, macFUSE est nécessaire
  • Les derniers builds de développement sont fournis sous forme d’exécutables uniques pour Linux et macOS
  • Les versions spécifiques sont disponibles sur la page des releases, et la version actuelle est 0.1.2
  • Il est aussi possible de le compiler depuis la source

Ressources liées et points de comparaison

  • Il existe l’article PLOS 2021 « Files-as-Filesystems for POSIX Shell Data Processing »
  • jq et gron sont des outils pour manipuler JSON en ligne de commande
  • ffs se distingue par sa prise en charge de plusieurs formats, la possibilité de modifier les données avec des outils shell familiers et l’absence de nouveau langage à apprendre
  • L’utilisation sous Windows, l’impossibilité d’utiliser FUSE, les tâches qui ne nécessitent que de la recherche et les très gros fichiers peuvent ne pas être adaptés à ffs
  • La licence est GPLv3

À lire aussi

1 commentaires

 
GN⁺ 2024-05-02
Avis sur Hacker News

  • C’est génial. Récemment, après avoir écrit un wrapper Nim pour libfuse, j’ai porté l’exemple de système de fichiers hello, et j’ai fait quasiment la même chose
    Ma version prend les données via un pipe et nécessite d’indiquer un point de montage ; une fois terminé, elle écrit le résultat sur la sortie standard. On peut donc l’insérer dans une chaîne de pipes, mais il faut aussi gérer la sortie soi-même
    En ce moment, j’explore si d’autres choses peuvent être transformées en systèmes de fichiers. J’ai aussi créé une barre d’état pour le gestionnaire de fenêtres Nimdow : en écrivant du contenu dans des fichiers individuels, on obtient en sortie une barre avec des blocs, ce qui permet de remplacer facilement le contenu de la barre
    Un autre outil que j’ai créé est un lecteur de musique basé sur libvlc. On lui donne un dossier, il lit les médias avec des tags ID3 et construit des dossiers comme by-artist, by-album. Chaque fichier s’appelle - et contient le chemin complet du fichier réel. Pour lire un morceau, on peut par exemple faire un cat d’un fichier vers control/current et écrire play dans control/command. Il y a d’autres fonctions de playlist et d’autres commandes, mais l’objectif est de faire un lecteur de musique très facile à scripter

    • Une idée : monter récursivement des fichiers de code ou des projets. Avec quelque chose comme tree-sitter, on pourrait extraire les définitions de classes et de fonctions, puis créer chacune d’elles comme un “fichier” dans le répertoire représentant le fichier réel
      Si l’on veut comprendre la structure d’une base de code, il suffit de lancer tree :)
      En allant plus loin, on pourrait peut-être résoudre les imports sous forme de liens symboliques, entre autres ; il y a beaucoup de possibilités intéressantes
    • Je serais curieux de savoir si tu peux partager le code Nim. Ça fait un moment que j’ai envie de faire quelque chose avec FUSE, et j’utilise Nim dans quelques projets
    • Je me dis qu’il serait bien d’avoir un mécanisme intégré pour exposer facilement les informations de processus sous forme de système de fichiers
      Par exemple, faire cat /proc/$pid/fs/current_track pour obtenir le nom du morceau en cours dans un lecteur de musique, ou ls /proc/$pid/fs/tabs pour voir la liste des onglets ouverts dans un navigateur. On pourrait peut-être même récupérer du HTML ou des images intégrées
      C’est déjà possible avec FUSE, mais c’est assez pénible pour que personne ne le fasse

  • C’est suffisamment utile pour devoir devenir une fonction standard au niveau du système d’exploitation
    Les systèmes de type Unix peuvent monter des images disque pour en parcourir le contenu. Mais lorsqu’on explore des fichiers à l’intérieur de fichiers, il y a bien plus de formats utiles. Les archives compressées en sont l’exemple typique
    Certains gestionnaires de fichiers prennent cela en charge, mais je ne pense pas que la couche applicative soit le meilleur endroit pour le faire. On pourrait l’implémenter comme des pilotes par format de fichier

    • Ce qu’il faut vraiment, c’est une façon d’écrire une commande de montage pour chaque format de fichier, ainsi qu’une commande séparée qui détecte le format et dispatch vers la bonne implémentation. Ce serait probablement proche de la commande file, et tout devrait pouvoir se faire en espace utilisateur
      Le seul facteur qui bloque aujourd’hui, c’est que MacOS n’expose pas d’API de système de fichiers en espace utilisateur. Sous Linux, Windows et BSD, c’est déjà possible
      Si un développeur Apple lit ceci : les extensions de fournisseur de fichiers ne suffisent pas. Donnez-nous l’équivalent de FUSE. Je sais que ça existe
    • Il existe déjà avfs. C’est un système de fichiers FUSE qui fait ça. Son utilisation n’est pas la plus intuitive, mais il fonctionne et il est extensible
      https://avf.sourceforge.net/
    • C’était une fonctionnalité de conception centrale de reiserfsv4, mais Linux a finalement refusé de l’intégrer. Le meurtre de sa femme n’a probablement pas aidé non plus
    • Je suis sincèrement curieux : en quoi est-ce utile ? J’ai du mal à voir des cas d’usage réellement pertinents
    • Je pensais que archivemount faisait déjà cela ; est-ce que j’ai raté quelque chose ?
      En tout cas, même si ce n’est pas exactement ce que tu veux, FUSE est un mécanisme plus général qui semble permettre de faire ce que tu souhaites, et même davantage

  • On peut aussi monter des commits git comme un système de fichiers
    https://jvns.ca/blog/2023/12/04/mounting-git-commits-as-fold...
    Article précédent : https://news.ycombinator.com/item?id=38527866

    • Il ne manque plus qu’un énorme tas de règles pour décider quelle révision choisir, et on obtient ce démon impie qu’est Rational ClearCase

  • En voyant le titre, j’ai espéré que c’était quelque chose que je cherchais autrefois, ou que j’avais envisagé de créer moi-même. C’est peut-être le bon endroit pour poser la question
    Existe-t-il un système de fichiers FUSE qui, tant qu’il est monté, fonctionne en mémoire comme tmpfs, puis se sérialise dans un fichier unique sur disque au moment du démontage ?
    Ce qui s’en rapproche le plus, ce sont les pilotes FUSE qui montent des fichiers d’archive, mais il devient alors difficile d’obtenir des choses comme les liens symboliques

    • Ce que j’ai trouvé de plus proche est https://github.com/guardianproject/libsqlfs
      libsqlfs implémente un système de fichiers de style POSIX au-dessus d’une base SQLite. Il fournit un système de fichiers en lecture/écriture, avec sa propre hiérarchie et son propre espace de noms à l’intérieur d’un fichier unique, et peut être utilisé comme bibliothèque partagée ou module FUSE
    • Ce n’est pas purement en mémoire, mais quelque chose comme https://github.com/jrwwallis/qcow2fuse pourrait peut-être convenir
      C’est rudimentaire comparé aux DMG d’OSX, mais avec un peu d’indulgence, cela atteint un objectif similaire
      Sinon, on pourrait envelopper tmpfs pour le sérialiser, au démontage, en tarball préservant les liens symboliques
    • Pourquoi faut-il absolument que ce soit en mémoire ?
      Tu le sais sans doute déjà, mais il existe de nombreux scénarios réalistes où ne flusher les buffers qu’au démontage peut entraîner une corruption des données
      Cela dit, le problème que tu essaies de résoudre semble intéressant
    • Est-ce que ça doit forcément être FUSE ? Ne peut-on pas monter une image disque en loopback ?
    • Rien exactement de ce genre ne me vient à l’esprit, mais copier une image dans /tmp, l’utiliser, puis la déplacer vers le disque après démontage devrait s’en rapprocher pas mal

  • Il existe aussi Parts-of-file File System : https://www.usenix.org/conference/2005-usenix-annual-technic...

  • Ça me fait penser à TabFS d’Omar Rizwan : <https://omar.website/tabfs/>

  • J’ai fait ça en 2003. Étonnamment, c’était rapide, et cela rendait le verrouillage fin facile
    Je l’utilisais comme base de données par utilisateur dans un langage de templates web pour un énorme outil de création de sites

  • En voyant le titre, j’ai cru que c’était un mème
    Mais c’est en fait une idée vraiment maligne. Personnellement, comme je fais la plupart de mes traitements de données dans des langages de plus haut niveau, je ne sais pas trop si je l’utiliserais directement, mais je pense que certains trouveront des cas d’usage
    C’est une bonne approche qui sort des sentiers battus

  • Ça a l’air vraiment bien, et je dois essayer ça dès que possible
    Je pense que ce serait très pratique pour parcourir ou rechercher dans des fichiers JSON

  • Si cela vous intéresse, Solvent-Configr pourrait aussi vous parler
    https://aws.amazon.com/marketplace/pp/prodview-i3ym46leenag4
    En modélisant des objets via un mécanisme de système de fichiers, on peut concevoir des solutions orientées objet qui prennent en charge une navigation à la manière d’un système de fichiers
    Démo : https://youtu.be/XgTgubZQPHw