Je te rejoins sur ce besoin d'indexation.
Par contre, implémenter ça sur un filesystem, c'est juste totalement insensé !
Mais on parle là de technos respectivement sorties ou abandonnées en 1995, 2004 et 2006.
C'est peut être pas pour rien ...
Pour répondre à ton "système" idéal:
quand on y dépose un fichier, le système commence par vérifier que ce fichier n'est pas déjà présent quelque part. En fonction des paramètres, cette vérification pourrait être stricte (identité bit à bit du contenu et des métadonnées), sur le contenu seul, ou plus souple (par exemple, si une photo identique à l'orientation près est trouvée, on peut décider de s'arrêter là ou non, de manière paramétrée ou interactive)
Wow, paye ton overhead lorsque tu copies les 14GiB de photo de la SD de 16GiB de ton reflex numérique sur ton FS et que ce dernier va devoir se palucher l'analyse de XXX * 2 (JPEG + RAW) fichiers de 40 MPixel... D'ailleurs, comment sont gérés les "duplicats logiques" dans ce cas (Aka: le RAW qui ressemble comme deux gouttes d'eau au JPEG de preview ?).
J'ai aucune envie que mon FS soit intelligent à ma place. Au contraire, il y a des fois ou la duplication est nécessaire et voulue (le RAW + JPEG de l'exemple précédent, FW livré à deux clients différents qui est en fait le même, la clef de crypto utilisé pour X produits différents, le .h commun à deux toolchains différentes, le morceau de tel artiste dans le CD de l'album ET dans le best of, etc...)
si un fichier est considéré comme nouveau, il est ajouté au système avec quelques tags qui sont générés automatiquement (type, date de création,...)
Bein c'est déjà ce qui est fait dans la "base de données" propre au filesystem.
en fonction du type, des plugins analysent le fichier pour en extraire des [méta]données qui sont proposées comme tags: les tags ID3 d'un MP3, les données EXIF d'un JPEG, les mots d'un document PDF ou ODT (avec un dictionnaire des mots à ne pas indexer, par exemple)
Non, définitivement non.
Pour peu que ton système soit pas customisée, tu vas rajouter encore de l'overhead en veux tu en voilà sans que le besoin réel existe dans 90% des cas (le webmaster qui pousse ses bannières & co, ses PDFs, etc...).
Sans compter que tu sembles oublier qu'il y a des tonnes de PDF, MP3, JPG, PNG installés sur le FS par ton gestionniaire de paquet et pour lesquels il n'y a aucun besoin d'indexation (icones, son de notification, docs, ...).
Et même si tu limites l'usage de ton FS au $HOME d'un desktop, tu vas te retrouver à analyser une tonne de choses inutilement (le cache de ton browser par exemple).
l'utilisateur peut aussi ajouter ses propres tags: sur la photo, c'est Durand, c'est l'anniversaire de la petite dernière, c'est le voyage de noces...
Ce n'est pas le rôle d'un FS.
Des plugins système pourraient permettre de taguer d'autres choses, comme les emails, par exemple (BeOS les indexait, je crois). En une recherche, on pourrait trouver les mails envoyés par Dupont et les photos sur lesquelles il apparaît et sa vCard.
On a déjà vu le résultat de ce type de features sur les smartphone ou dans les environnements de bureau tout intégrés (GNOME avec Evolution, Pidgin & co; Kde aussi j'imagine): ça marche mal. Parce qu'un coup, Dupont envoie ses mails depuis son téléphone, et là t'as "Benjamin D." dans le From:, d'autres coups depuis son PC et t'as "Ben Dupont", l'autre fois depuis son PC du taf et tu te choppes "Benjamin Dupont - Evil Corp. - Software Engineer"...
Bien sûr, je parle ici de tout ce qu'on peut considérer comme un document
Ok... et c'est quoi un document ?
Chaque usage à sa définition, le fan de retouche photo, le gamer, l'écrivain en herbe, les besoins sont aussi nombreux que les gouts de chacun.
Après, tu évoques plusieurs fois un système de plugin ... mais tu parles de filesystem !
Pour rappel, tu as:
* Les filesystems kernel-land, les plus performants et robustes.
* Les filesystems type FUSE, moins performants car implémentés en user-land et de robustesse très variable.
J'imagine que dans ton idéal de FS, tu le voudrais kernel-land ... vu l'overhead que tu vas ajouter, si en plus c'est full user-land, tu vas avoir l'impression que ton SSD s'est transformé en disque IDE UDMA33 !
Et donc, de ce coup, pour remplir ton besoin, il va falloir implémenter en kernel-land:
* Le parsing des JPEGs.
* Le parsing des EXIFS.
* Le parsing des MP3.
* Le parsing des PDFs.
* Le parsing de ...
* Des algos de reconnaissance faciales
* Des algos de reconnaissance de son (MP3 en 128kbit/s d'un côté, MP3 en 256kbit/s ou FLAC de l'autre)
Tu vois ou je veux en venir ? Le kernel, c'est une librairie C très limitée et il n'y a rien aujourd'hui pour faire ce que tu évoques...
La seule chose pour répondre partiellement à ton besoin, ça va être le sous-système crypto qui va te permettre de faire des hash de fichier pour vérifier les duplicats...
En outre, tu sembles oublier l'un des principes les plus importants de la philosophie Unix: le Principe_KISS.
Un système de fichiers, c'est fait pour stocker des fichiers. POINT. La force d'un système de fichier avec cette hierarchisation par répertoire, c'est que ça marche bien et que tout est fichier. C'est simple à backuper, que ce soit en bourrin ou en incrémental, c'est simple de rechercher les différences, c'est simple de lister, et c'est simple d'organiser à sa sauce.
Si tu veux indexer les dits fichier, utilise un soft qui est fait pour ça, configure le pour qu'il indexe les fichiers qui t'intéressent dans les repertoires qui t'intéressent selon les critères qui t'intéresse.
Je te rejoins totalement sur la pertinence du besoin.
Mais de mon humble point de vue, il ne faut pas implémenter ça dans un filesystem en kernel-land.
Il faut plutôt faire un daemon qui se configure (analyse les PDF || JPG dans ~/Documents, mes MP3 dans ~/Musique, ...) et utilise ensuite inotify pour surveiller les fichiers et faire l'indexation en tâche de fond. Si le soft découvre des doublons, il pousse une notification sur D-bus, notification récupérée par l'applet dédiée qui t'informe du doublon et te demande l'action à prendre.
Je crois qu'il y a pas mal de soft existant dans ce domaine, une recherche google "file indexer linux" renvoie pas mal de résultat en tout cas...
# Aucun intérêt réel.... voir même une totale ineptie.
Posté par LaBienPensanceMaTuer . En réponse au journal Où sont les filesystems orientés DB?. Évalué à 10.
Je te rejoins sur ce besoin d'indexation.
Par contre, implémenter ça sur un filesystem, c'est juste totalement insensé !
C'est peut être pas pour rien ...
Pour répondre à ton "système" idéal:
.hcommun à deux toolchains différentes, le morceau de tel artiste dans le CD de l'album ET dans le best of, etc...)Bein c'est déjà ce qui est fait dans la "base de données" propre au filesystem.
Non, définitivement non.
Pour peu que ton système soit pas customisée, tu vas rajouter encore de l'overhead en veux tu en voilà sans que le besoin réel existe dans 90% des cas (le webmaster qui pousse ses bannières & co, ses PDFs, etc...).
Sans compter que tu sembles oublier qu'il y a des tonnes de PDF, MP3, JPG, PNG installés sur le FS par ton gestionniaire de paquet et pour lesquels il n'y a aucun besoin d'indexation (icones, son de notification, docs, ...).
Et même si tu limites l'usage de ton FS au $HOME d'un desktop, tu vas te retrouver à analyser une tonne de choses inutilement (le cache de ton browser par exemple).
Ce n'est pas le rôle d'un FS.
On a déjà vu le résultat de ce type de features sur les smartphone ou dans les environnements de bureau tout intégrés (GNOME avec Evolution, Pidgin & co; Kde aussi j'imagine): ça marche mal. Parce qu'un coup, Dupont envoie ses mails depuis son téléphone, et là t'as "Benjamin D." dans le From:, d'autres coups depuis son PC et t'as "Ben Dupont", l'autre fois depuis son PC du taf et tu te choppes "Benjamin Dupont - Evil Corp. - Software Engineer"...
Ok... et c'est quoi un document ?
Chaque usage à sa définition, le fan de retouche photo, le gamer, l'écrivain en herbe, les besoins sont aussi nombreux que les gouts de chacun.
Après, tu évoques plusieurs fois un système de plugin ... mais tu parles de filesystem !
Pour rappel, tu as:
* Les filesystems kernel-land, les plus performants et robustes.
* Les filesystems type FUSE, moins performants car implémentés en user-land et de robustesse très variable.
J'imagine que dans ton idéal de FS, tu le voudrais kernel-land ... vu l'overhead que tu vas ajouter, si en plus c'est full user-land, tu vas avoir l'impression que ton SSD s'est transformé en disque IDE UDMA33 !
Et donc, de ce coup, pour remplir ton besoin, il va falloir implémenter en kernel-land:
* Le parsing des JPEGs.
* Le parsing des EXIFS.
* Le parsing des MP3.
* Le parsing des PDFs.
* Le parsing de ...
* Des algos de reconnaissance faciales
* Des algos de reconnaissance de son (MP3 en 128kbit/s d'un côté, MP3 en 256kbit/s ou FLAC de l'autre)
Tu vois ou je veux en venir ? Le kernel, c'est une librairie C très limitée et il n'y a rien aujourd'hui pour faire ce que tu évoques...
La seule chose pour répondre partiellement à ton besoin, ça va être le sous-système crypto qui va te permettre de faire des hash de fichier pour vérifier les duplicats...
En outre, tu sembles oublier l'un des principes les plus importants de la philosophie Unix: le Principe_KISS.
Un système de fichiers, c'est fait pour stocker des fichiers. POINT. La force d'un système de fichier avec cette hierarchisation par répertoire, c'est que ça marche bien et que tout est fichier. C'est simple à backuper, que ce soit en bourrin ou en incrémental, c'est simple de rechercher les différences, c'est simple de lister, et c'est simple d'organiser à sa sauce.
Si tu veux indexer les dits fichier, utilise un soft qui est fait pour ça, configure le pour qu'il indexe les fichiers qui t'intéressent dans les repertoires qui t'intéressent selon les critères qui t'intéresse.
Je te rejoins totalement sur la pertinence du besoin.
Mais de mon humble point de vue, il ne faut pas implémenter ça dans un filesystem en kernel-land.
Il faut plutôt faire un daemon qui se configure (analyse les PDF || JPG dans ~/Documents, mes MP3 dans ~/Musique, ...) et utilise ensuite
inotifypour surveiller les fichiers et faire l'indexation en tâche de fond. Si le soft découvre des doublons, il pousse une notification sur D-bus, notification récupérée par l'applet dédiée qui t'informe du doublon et te demande l'action à prendre.Je crois qu'il y a pas mal de soft existant dans ce domaine, une recherche google "file indexer linux" renvoie pas mal de résultat en tout cas...