fusebox : transformations composées sur des systèmes de fichiers FUSE

Chers tous, voici un petit projet qui me faisait envie depuis longtemps et que j'ai réalisé récemment.

Il s'agit d'utiliser FUSE pour enchaîner des transformations simples, et surtout spécifiées de façon concise sans errno ni masques bit-à-bit, sur une arborescence de fichiers existante : filtrer les fichiers affichés, changer le nom ou le contenu des fichiers, etc.

🇬🇧 https://github.com/nahoj/fusebox-fs

Le projet prend la forme d'une bibliothèque Java, appelable depuis des scripts JBang par exemple.

Q : Keuwah ?! Mais pourquoi un langage aussi peu cool ?
R : Parce que c'était un des langages que je connaissais qui avait des bindings FUSE. Parce que le typage fort est très appréciable pour comprendre ce qu'on fait, par rapport à Python. Parce que j'aurais pu coder en Scala ou Kotlin mais que, faisant du Java au boulot, je n'avais pas envie de me mettre à confondre les syntaxes.

Exemple : Voici un script qui monte une vue d'une arborescence de fichiers dans laquelle les fichiers Markdown sont remplacés par leur traduction en HTML :

    FuseboxFS fs = LocalFS.at("/dossier/source")
            // On va transformer uniquement les fichiers en .md
            .mapFiles(glob("**.md"), file ->  
                    // (Le nouveau contenu est en lecture seule)
                    file.mapContent(content -> content.mapAsString(md ->
                            mdToHtml(file.name(), md)
                    ))
            )
            // On a maintenant des fichiers .md qui contiennent du HTML.
            // Tout renommage doit être défini dans les 2 sens
            .mapNames(glob("**.md"), glob("**.html"),
                    name -> name.substring(0, name.length() - 3) + ".html",
                    name -> name.substring(0, name.length() - 5) + ".md"
            );
    Fusebox.mount("markdown_to_html", fs, "/point/de/montage");

Le script complet fait 50 lignes.

⚠️ Attention : ceci est expérimental et très peu testé. Toute utilisation est à vos risques et périls.

Les 2 sens de lecture

Mon but était de pouvoir définir des transformation en partant d'une arborescence de fichiers existante, comme sur des Stream ou autre collection dans tout langage un tant soit peu fonctionnel.

Cependant, je voulais un fonctionnement dynamique, potentiellement en lecture-écriture, et non un chargement de tous les fichiers sources pour les transformer.

Or, le résultat doit être un système de fichiers qui reçoit des chemins relatifs au point de montage, et détermine le contenu des fichiers correspondants par exemple.

Une transformation sur les noms de fichiers (par exemple) doit donc être définie dans les 2 sens :
- le sens origine → point de montage, pour lister les entrées d'un dossier, par exemple ;
- le sens point de montage → origine, pour retrouver le contenu des fichiers en partant du point de montage.

Implémentation

Dans sa version actuelle, fusebox utilise Apache Commons VFS comme backend et jfuse pour monter le système de fichier transformé.

Les interfaces de la bibliothèque sont inspirées de celles de VFS (FuseboxFS, FuseboxFile, FuseboxContent pour FileSystem, FileObject, FileContent chez VFS), mais simplifiées et adaptées au besoin.

L'implémentation actuelle est partielle, il manque notamment l'écriture et le déplacement de fichiers.

J'ai laissé visible dans le dépôt l'implémentation précédente, à base de java.nio, qui est beaucoup plus complète, quoiqu'un peu moins élégante.

Conclusion

Est-ce que tout ceci sert réellement à quelque chose ? Ça reste à voir ! Si sous Unix, « tout est fichier », alors, ~~le ciel~~ Long.MAX_VALUE est la limite ?

Dans tous les cas, je serais ravi de lire vos commentaires et, sait-on jamais, vos retours d'utilisation !