Le type de recherche que vous voulez n'est pas clair. Si vous voulez que cela fonctionne n'importe où dans Unix, plutôt que seulement dans votre répertoire personnel, et que vous voulez seulement faire des recherches basées sur les noms de chemin, le schéma suivant est réalisable, avec un peu de bidouillage Shell, et en utilisant le standard locatedb :
- Chaque répertoire qui contient au moins un fichier étiqueté a besoin d'un sous-répertoire standard, par exemple
.path-tags ;
- Chaque fichier du répertoire $FILE ayant un lien $TAG (qui ne doit pas contenir le char
_ ) a un lien $TAG_$FILE -> ../$FILE
Je laisse les détails de la locate-tag script pour vous ; il devrait être de deux ou trois lignes, utilisant seulement le locate et Shell. (Si vous êtes intéressé, je pourrais en écrire un).
Certains membres de KDE ont parlé de ce type de schéma pour les métadonnées, mais je ne me souviens pas des détails.
Il devrait également être possible de faire des tests plus sophistiqués, examinant le contenu, basés sur ce schéma avec un script similaire enveloppé autour de find .
Réflexions sur les exigences actualisées
-
tout fichier lisible par l'utilisateur peut être étiqueté librement - Oui, cela ne devrait pas poser de problème
-
un utilisateur peut rechercher des fichiers correspondant à un ou plusieurs tags - De même
-
les fichiers peuvent être déplacés sans perdre les balises qui leur étaient précédemment associées. - Les répertoires qu'ils occupent peuvent être déplacés librement, mais si le fichier est déplacé du répertoire, nous avons des problèmes. Si les balises prenaient la forme
$TAG_$INODE_$FILE et nous avons un moyen efficace de trouver quels chemins ont un inode donné Nous pouvons alors le faire, en ne perdant les balises que si nous sortons des systèmes de fichiers. La copie de fichiers pourrait poser quelques problèmes, et c'est clairement plus compliqué que ma suggestion initiale.
-
le système peut être sauvegardé facilement - pas essentiellement difficile.
-
aucune dépendance à l'égard d'un environnement de bureau - aucun
-
si une interface graphique est impliquée, il doit y avoir une solution de repli pour le client. - c'est là que nous vivons !
Post-scriptum 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 inverse, qui vérifie que chaque inode donné dans le nom de fichier d'une balise correspond à l'inode du fichier (s'il existe) vers lequel pointe la balise. S'il n'y a pas de correspondance, alors la chirurgie requise peut être effectuée (est-ce que l'inode existe toujours ? où est-il ?), et le fichier de consultation inverse est soit muté soit régénéré, et les liens symboliques des balises sont mis à jour.
Je prévois un cas délicat : que se passe-t-il si le fichier balisé n'est pas là où les balises indiquent qu'il devrait être, que le fichier de recherche inverse indique qu'il existe toujours, mais que le fichier prodigue n'est pas là où le fichier de recherche indique qu'il est, le fichier de recherche étant périmé ? Il y a plusieurs façons de traiter ce cas, aucune n'étant évidemment idéale. En dehors de cela, toute cette tâche semble être le genre de chose pour laquelle Perl est bien adapté...
