Il n'est pas clair quel type de recherche que vous voulez. Si vous voulez que cela fonctionne n'importe où dans Unix, plutôt que juste dans votre répertoire personnel, et que vous voulez seulement faire des recherches basées sur les noms de chemins, le schéma suivant est réalisable, avec un peu de piratage de shell et en utilisant la norme locatedb:
- Chaque répertoire contenant au moins un fichier étiqueté nécessite un sous-répertoire standard, par exemple
.path-tags;
- Chaque fichier du répertoire $ FILE avec le lien $ TAG (qui ne doit pas contenir le caractère
_) a un lien$TAG_$FILE -> ../$FILE
Je vous laisse les détails du locate-tagscript; il devrait s'agir de deux ou trois locatelignes , n'utilisant que la commande et le hackery shell. (Si cela vous intéresse, je pourrais en écrire un).
Certains des responsables de KDE ont parlé de ce type de schéma pour les métadonnées, bien que je ne me souvienne pas des détails.
Il devrait également être possible de réaliser des tests d’examen du contenu plus sophistiqués basés sur ce schéma, avec un script similaire encapsulé find.
Réflexions sur les exigences mises à jour
- tout fichier lisible par l'utilisateur peut être étiqueté librement - Oui, cela ne devrait poser aucun problème
- un utilisateur peut rechercher des fichiers correspondant à une ou plusieurs balises - De même
- les fichiers peuvent être déplacés sans perdre les balises précédemment associées - Les répertoires qu’ils habitent peuvent être librement déplacés, mais si le fichier est déplacé du répertoire, nous avons des problèmes. Si les balises ont pris la forme
$TAG_$INODE_$FILEet que nous avons un moyen efficace de trouver les chemins qui ont un inode donné , nous pouvons le faire, en perdant les balises seulement si nous sortons des systèmes de fichiers. La copie de fichiers peut poser problème, ce qui est nettement plus compliqué que ma suggestion initiale.
- le système pourrait être sauvegardé facilement - pas vraiment difficile.
- aucune dépendance sur aucun environnement de bureau - aucune
- si une interface graphique est impliquée, il doit y avoir une solution de rechange cli - c'est là que nous vivons!
Postscript
Le fichier "reverse-inode-lookup" décrit par le lien (2) que vous m'avez montré dans votre réponse à (1) peut être utilisé pour fournir une infrastructure supplémentaire. Nous pouvons exécuter un service sur le fichier de recherche inversée, qui vérifie que chaque inode indiqué dans le nom de fichier d'une balise correspond à l'inode du fichier (le cas échéant) pointé par la balise. S'il n'y a pas de correspondance, alors l'opération requise peut être effectuée (l'inode existe-t-il toujours? Où est-il?), Le fichier de recherche inversée étant muté ou régénéré, et les liens symboliques de balises étant mis à jour.
J'anticipe un cas délicat: que se passe-t-il si le fichier balisé n'est pas où les balises disent qu'il devrait être, le fichier de recherche inversée dit qu'il existe toujours, mais le fichier prodigue n'est pas où le fichier de recherche indique qu'il est, le fichier de recherche étant hors de Date? Il existe plusieurs façons de traiter cette affaire, aucune n’est manifestement idéale. En dehors de cela, toute cette tâche semble être le genre de chose à laquelle Perl est bien adapté ...
