Fichier "virtuel" généré à la volée ?

Salut,

Le titre n’est pas très évocateur, mais je n’ai pas trouvé mieux comme description…

Mon but est de pouvoir créer un fichier (accessible en lecture seule) qui, à chaque fois qu’il est lu par n’importe quelle application, exécute un shell/script/programme particulier pour générer le contenu à la volée.
Pour des raisons pratiques c’est important que ça soit vu comme un simple fichier par l’application qui le lit, et non pas comme un script exécutable.

Exemples :

[code]cp fichier_virtuel autre_fichier
#équivalent à
/chemin/script_virtuel > autre_fichier

cat fichier_virtuel | grep…
#équivalent à
/chemin/script_virtuel | grep…[/code]

Vous me demanderez, pourquoi me torturer la tête alors que le shell permet de faire ça avec de simples pipes / redirections ? Tout simplement parce que je souhaite que ça fonctionne avec n’importe quelle application qui utilise un bon vieux fopen/fread en C.

D’où ma question : peut-on réaliser ça avec des outils déjà disponibles ? Faudrait-il plutôt faire un développement spécifique, et à quel niveau (userland/kernel) ?

Salut,

À priori incron devrait faire l’affaire.
Et un autre article peut être plus évocateur à son sujet.

C’est difficilement visible comme un autre fichier, les fonctions lseek et write auront du mal à marcher. Pour ça, je ne vois qu’un fichier spécial et un module du noyau qui à chaque ouverture fabrique le fichier (via une commande fournit en argument) dans /tmp et renvoit le descripteur de fichier. Pas trop dur à faire mais il faut le coder, avec le débuguage et le rappel du codage des appels noyaux je vois une semaine de boulot bien tassée… :confused:

incron fait l’inverse, il execute un programme à chaque modification d’un fichier.

Tout d’abord, merci pour ces réponses.

[quote="…"]À priori incron devrait faire l’affaire.[/quote]Je ne connaissais pas !
Dans l’absolu, on devrait effectivement pouvoir utiliser le flag IN_OPEN sur le fichier “spécial” pour regénérer son contenu lors de son ouverture. Mais je soupçonne qu’il y aura des problèmes de concurrence (ie. l’application commencera à lire le fichier pendant que incron sera en train d’exécuter la commande).

Par contre, en prenant le problème par l’autre bout, je devrais pouvoir arriver à faire ce que je veux. En effet, les scripts que j’ai besoin d’exécuter se basent sur le contenu d’autres fichiers, donc en utilisant IN_MODIFY ou IN_CLOSE_WRITE sur ces fichiers “source” je pourrai à priori regénérer le contenu du fichier “spécial”. Tant pis pour l’élégance de la solution générique.

[quote=“fran.b”]C’est difficilement visible comme un autre fichier, les fonctions lseek et write auront du mal à marcher.[/quote]Bien vu, je n’avais pas pensé au seek. Par contre j’avais écarté le write d’emblée (aucune utilité dans mon cas), mais maintenant je me rends compte que certaines applications ont besoin d’ouvrir les fichiers en écriture, même si je ne compte pas conserver leurs modifications.

[quote=“fran.b”]Pour ça, je ne vois qu’un fichier spécial et un module du noyau qui à chaque ouverture fabrique le fichier (via une commande fournit en argument) dans /tmp et renvoit le descripteur de fichier. Pas trop dur à faire mais il faut le coder, avec le débuguage et le rappel du codage des appels noyaux je vois une semaine de boulot bien tassée…[/quote]C’est bien ce que je craignais. Et là, je me heurte à un problème : malgré une solide expérience en C et surtout C++, je n’ai jamais mis le nez dans le kernel (donc, compter plutôt 2 à 3 semaines de boulot dans mon cas).
Non pas que ça soit bloquant, mais j’ai déjà suffisamment tendance à me disperser et je préférerais éviter ce type de R&D alors que pour le moment j’ai vraiment besoin d’être productif. Je vais quand même garder ça dans un coin de ma tête, ça serait intéressant de le faire si l’occasion se présente (lire : quand je n’aurai rien de mieux à faire).

En conclusion, je vais essayer incron, en espérant que ça ne sorte jamais du cas de figure que j’ai expliqué plus haut.

Merci encore, je vous tiens au courant lorsque/si ça marche.

Ça marche impeccablement…

Petite remarque qui peut servir (j’ai mis un moment à trouver) : la documentation complète des flags est dans man -s 5 incrontab et non pas simplement man incrontab.

Un flag bien utile étant IN_NO_LOOP, qui empêche incron de s’appeler récursivement lorsque la commande exécutée provoque un évènement sur un fichier/répertoire surveillé.

Exemple simple :

[code]# Boucle infinie, 100% CPU
/chemin IN_CLOSE_WRITE cat /chemin/f1 /chemin/f2 > /chemin/resultat

Problème résolu

/chemin IN_CLOSE_WRITE,IN_NO_LOOP cat /chemin/f1 /chemin/f2 > /chemin/resultat[/code]