> Reiser 4 supporte aussi l'association de méta-données aux fichiers.
Ext3 le permet aussi et probablement beaucoup d'autres.
> Ceci permettrait (je n'ai pas bien compris comment) de pouvoir faire des recherches très fines sur les fichiers. Un peu comme Beagle le fait, mais au niveau du système de fichier
Sur le papier c'est mignon mais dans la pratique c'est quasiment sans intérêt.
Imaginons que dans les méta-données tu mets le nom de l'auteur du fichier (fichier txt, ou ogg, ...). Que doit faire apache s'il doit servir ces fichiers ? Il doit envoyer les méta-données avec le fichier ? Que doit faire le client web (firefox) ? Que ce passe-t-il si tu mets ces fichiers sur un serveur NFS ou SMB ? Et si le fichier est join à un mail ?
Avec méta-données tu fais :
- read(fichier)
- read_meta_data(fichier)
Sans méta-données tu peux faire :
- read(fichier)
- read(fichier.meta_data)
Sans méta-données tu peux faire :
- read(fichier) : et dans le fichier tu mets les "méta-données", comme openoffice stocke le nom de l'auteur et d'autres attributs dans les fichiers qu'il crée.
La seconde et troisième solutions marchent partout (apache, smb, nfs, client web, etc...).
La troisième solutions est la meilleure et de loins la plus utilisée.
La seconde est plus souple.
L'avantage de la première sur la seconde est une meilleur gestion des espaces de nom. Exemple : si "fichier" supprimé alors supprimer méta-données de "fichier" (le noyau peut faire ça systématiquement). Par contre avec la seconde solution, c'est aux programmes de le faire.
Il y a aussi les méta-données par fichier dédiés à un programme. Par exemple nautilus a ses méta-données par fichier/répertoire (définition de la taille de la fenêtre pour le répertoire "rep", sa couleur, etc).
Ben que ça soit dans ~/.nautilus ou dans de "vrais" méta-données ne change par grand chose. Et à y réflécher la première solution est sûrement la meilleure.
[^] # Re: Pour les nul ?
Posté par clearstream . En réponse au journal Et Reiser4 nous apprend comment fonctionne la communauté. Évalué à 2.
Ext3 le permet aussi et probablement beaucoup d'autres.
> Ceci permettrait (je n'ai pas bien compris comment) de pouvoir faire des recherches très fines sur les fichiers. Un peu comme Beagle le fait, mais au niveau du système de fichier
Sur le papier c'est mignon mais dans la pratique c'est quasiment sans intérêt.
Imaginons que dans les méta-données tu mets le nom de l'auteur du fichier (fichier txt, ou ogg, ...). Que doit faire apache s'il doit servir ces fichiers ? Il doit envoyer les méta-données avec le fichier ? Que doit faire le client web (firefox) ? Que ce passe-t-il si tu mets ces fichiers sur un serveur NFS ou SMB ? Et si le fichier est join à un mail ?
Avec méta-données tu fais :
- read(fichier)
- read_meta_data(fichier)
Sans méta-données tu peux faire :
- read(fichier)
- read(fichier.meta_data)
Sans méta-données tu peux faire :
- read(fichier) : et dans le fichier tu mets les "méta-données", comme openoffice stocke le nom de l'auteur et d'autres attributs dans les fichiers qu'il crée.
La seconde et troisième solutions marchent partout (apache, smb, nfs, client web, etc...).
La troisième solutions est la meilleure et de loins la plus utilisée.
La seconde est plus souple.
L'avantage de la première sur la seconde est une meilleur gestion des espaces de nom. Exemple : si "fichier" supprimé alors supprimer méta-données de "fichier" (le noyau peut faire ça systématiquement). Par contre avec la seconde solution, c'est aux programmes de le faire.
Il y a aussi les méta-données par fichier dédiés à un programme. Par exemple nautilus a ses méta-données par fichier/répertoire (définition de la taille de la fenêtre pour le répertoire "rep", sa couleur, etc).
Ben que ça soit dans ~/.nautilus ou dans de "vrais" méta-données ne change par grand chose. Et à y réflécher la première solution est sûrement la meilleure.
> plus rapide donc ?
Je ne vois pas pourquoi.