> C'est à dire qu'il ne faut pas lire le fichier pour avoir les méta données
Comme ext3.
> Mais le contraire est possible, c'est à dire de retrouver le fichier par les méta données, et c'est là tout l'interet
Ok, c'est différent. Donc c'est en gros comme une base de données.
> Le probleme c'est de comment suivre l'activité des fichiers
Si le méta-donnée
> Et venez pas me parler de inotify
Et pourquoi ? Dnotify avait des limitations embêtantes (beaucoup de descripteurs de fichier ouverts). Mais inotify semble plus que correcte (testé avec un noyau 2.6.17) .
Tu peux jouer avec : http://inotify-tools.sourceforge.net/
> Du côté du kernel c'est à voir, si on peut faire en userland on fait (un / en Fuse ca se tente non? :)
Je ne reviendrait pas sur ce que je pense de "toussa". Si je me trompe tant mieux.
Si je devais le faire, ça serait autour de :
- un gestionnaire de base de donnée (style db4). Une base de donnée par utilisateur.
- une librairie cliente pour que ça soit mieux intégré aux programmes qui le désire. Permet aussi aux programmes clients de dire "ignore les changements reporté par inotify, c'est moi qui les communiquerait.". Ca serait bien aussi pour être intégré à nautilus.
- des utilitaires en ligne de commande pour faire des requêtes, utiliser dans des scripts shell, faire des dump/restore etc...
- un serveur pour être à l'écoute des changements, intéroger, etc... Probablement utilisé via dbus. Ca ne serait pas un serveur sur l'ensemble du système mais seulement par utilisateur.
- un système de plugin pour le serveur afin d'avoir des "helpers" pour extraire les méta-données des fichiers. Par exemple oowriter a enregistré un fichier, inotify le signale au serveur, le serveur en utilisant l'helper extrait ces donnés puis les stock. Les helpers pourrait ainsi être fournis par les programmes.
- inotify. Seul le serveur utiliserait inotify. En fait plus probablement utilisation de gamin (qui utilise inotify). Permettrait de suivre les suppressions de fichier, les déplacements, etc...
- au lancement du serveur, un contrôle de la cohérence méta-donnée donnée serait fait (dans le cas où des fichiers sont supprimés, renommés, etc depuis le dernier état connu). Il est claire que stocker que numéros la pair dev/inode/mdate peut aider pour si retourner a rattraper les changements.
Une des grosses difficultées selon moi, est de standardiser les données qui seront stocké.
Il y a aussi le lourd problème de la configuration. Il faudrait pourvoir dire :
- pour ce répertoire, tu ne fais rien
- pour cet autre répertoire, je veux que tu "marques" chaque fichier comme étant de la catégorie "projet : dupond" et que tu me demandes d'enregistrer des mots clés sauf pour les fichiers openoffice où tu récupères les valeurs directement du fichier.
C'est horriblement compliqué.
Avec reiserfs, c'est un gain pour les déplacements/suppression de fichier et... c'est tout. Par contre si on est dépendant de reiserfs, et bien ca ne marche d'avec reiserfs. C'est très limitant.
Je ne prévois rien pour ceux qui se logguent sur une console texte. Sauf la disponibilité des outils (faire un dump, faire une modification à la main, etc).
Je signale que je ne me suis jamais réellement penché sur le problème et d'ailleurs je n'ai jamais utilisé kat ou beagle.
[^] # Re: Pour les nul ?
Posté par clearstream . En réponse au journal Et Reiser4 nous apprend comment fonctionne la communauté. Évalué à 2.
Comme ext3.
> Mais le contraire est possible, c'est à dire de retrouver le fichier par les méta données, et c'est là tout l'interet
Ok, c'est différent. Donc c'est en gros comme une base de données.
> Le probleme c'est de comment suivre l'activité des fichiers
Si le méta-donnée
> Et venez pas me parler de inotify
Et pourquoi ? Dnotify avait des limitations embêtantes (beaucoup de descripteurs de fichier ouverts). Mais inotify semble plus que correcte (testé avec un noyau 2.6.17) .
Tu peux jouer avec :
http://inotify-tools.sourceforge.net/
> Du côté du kernel c'est à voir, si on peut faire en userland on fait (un / en Fuse ca se tente non? :)
Je ne reviendrait pas sur ce que je pense de "toussa". Si je me trompe tant mieux.
Si je devais le faire, ça serait autour de :
- un gestionnaire de base de donnée (style db4). Une base de donnée par utilisateur.
- une librairie cliente pour que ça soit mieux intégré aux programmes qui le désire. Permet aussi aux programmes clients de dire "ignore les changements reporté par inotify, c'est moi qui les communiquerait.". Ca serait bien aussi pour être intégré à nautilus.
- des utilitaires en ligne de commande pour faire des requêtes, utiliser dans des scripts shell, faire des dump/restore etc...
- un serveur pour être à l'écoute des changements, intéroger, etc... Probablement utilisé via dbus. Ca ne serait pas un serveur sur l'ensemble du système mais seulement par utilisateur.
- un système de plugin pour le serveur afin d'avoir des "helpers" pour extraire les méta-données des fichiers. Par exemple oowriter a enregistré un fichier, inotify le signale au serveur, le serveur en utilisant l'helper extrait ces donnés puis les stock. Les helpers pourrait ainsi être fournis par les programmes.
- inotify. Seul le serveur utiliserait inotify. En fait plus probablement utilisation de gamin (qui utilise inotify). Permettrait de suivre les suppressions de fichier, les déplacements, etc...
- au lancement du serveur, un contrôle de la cohérence méta-donnée donnée serait fait (dans le cas où des fichiers sont supprimés, renommés, etc depuis le dernier état connu). Il est claire que stocker que numéros la pair dev/inode/mdate peut aider pour si retourner a rattraper les changements.
Une des grosses difficultées selon moi, est de standardiser les données qui seront stocké.
Il y a aussi le lourd problème de la configuration. Il faudrait pourvoir dire :
- pour ce répertoire, tu ne fais rien
- pour cet autre répertoire, je veux que tu "marques" chaque fichier comme étant de la catégorie "projet : dupond" et que tu me demandes d'enregistrer des mots clés sauf pour les fichiers openoffice où tu récupères les valeurs directement du fichier.
C'est horriblement compliqué.
Avec reiserfs, c'est un gain pour les déplacements/suppression de fichier et... c'est tout. Par contre si on est dépendant de reiserfs, et bien ca ne marche d'avec reiserfs. C'est très limitant.
Je ne prévois rien pour ceux qui se logguent sur une console texte. Sauf la disponibilité des outils (faire un dump, faire une modification à la main, etc).
Je signale que je ne me suis jamais réellement penché sur le problème et d'ailleurs je n'ai jamais utilisé kat ou beagle.