Je viens de publier une version alpha de mon nouveau programme qui tente de fournir cette fonctionnalité. Il répond actuellement à certaines de vos exigences, mais pas à toutes. Cela peut quand même vous intéresser. Il fournit un outil de ligne de commande pour le balisage et un système de fichiers virtuel pour la navigation (où les balises sont représentées par des répertoires).
http://www.tmsu.org/
tout fichier lisible par l'utilisateur peut être tagué librement
Oui.
un utilisateur peut rechercher des fichiers correspondant à une ou plusieurs balises
Oui. Soit via l'outil de ligne de commande, soit en parcourant les répertoires de balises dans le système de fichiers virtuel.
les fichiers peuvent être déplacés sans perdre les balises précédemment associées
Non. Cependant, l'application stocke les empreintes digitales des fichiers marqués qui sont utilisées pour aider à identifier les fichiers déplacés. Une commande 'réparer' est fournie pour mettre à jour les chemins des fichiers déplacés. (Évidemment, ce mécanisme tombe en panne si un fichier est à la fois déplacé et modifié.)
le système pourrait être sauvegardé facilement
Oui. C'est un simple fichier de base de données SQLite 3.
aucune dépendance sur aucun environnement de bureau
Oui. Aucune dépendance et comme il peut être exécuté en tant que système de fichiers virtuel, il est disponible pour être utilisé en tant que système de fichiers dans n'importe quel programme prenant en charge les liens symboliques.
si une interface graphique est impliquée, il doit y avoir une solution de repli cli
Pas d'interface graphique pour le moment.
Le type de recherche que vous souhaitez n'est pas clair. Si vous souhaitez qu'il fonctionne n'importe où sous Unix, plutôt que dans votre répertoire personnel, et que vous ne souhaitiez effectuer que des recherches basées sur le nom de chemin, le schéma suivant est réalisable, avec un peu de piratage shell et en utilisant le standard locatedb :
- Chaque répertoire contenant au moins un fichier balisé a besoin d'un sous-répertoire standard, disons
.path-tags; - Chaque fichier dans le répertoire $FILE avec le lien $TAG (qui ne doit pas contenir le caractère
_) a un lien$TAG_$FILE -> ../$FILE
Je laisse les détails du locate-tag script pour vous; ce devrait être un deux ou trois lignes, en utilisant uniquement le locate commande et piratage du shell. (Si ça vous intéresse, je pourrais en écrire un).
Certains des gars 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 faire des tests d'examen de contenu plus sophistiqués basés sur ce schéma avec un script similaire enroulé autour de find .
Réflexions sur les exigences mises à jour
- tout fichier lisible par l'utilisateur peut être balisé librement - Oui, cela ne devrait pas poser de 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 tags ont pris la forme
$TAG_$INODE_$FILEet nous avons un moyen efficace de trouver quels chemins ont un inode donné, alors nous pouvons le faire, en perdant des balises uniquement si nous quittons les systèmes de fichiers. La copie de fichiers peut poser des problèmes, et c'est clairement plus compliqué que ma suggestion initiale. - le système peut être sauvegardé facilement - pas essentiellement difficile.
- pas de dépendances sur un environnement de bureau - aucun
- si une interface graphique est impliquée, il doit y avoir une solution de repli cli - 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 donner une infrastructure supplémentaire. Nous pouvons exécuter un service sur le fichier de recherche inversée, qui vérifie que chaque inode donné dans le nom de fichier d'une balise correspond à l'inode du fichier (le cas échéant) vers lequel la balise pointe. S'il n'y a pas de correspondance, alors la chirurgie requise peut être effectuée (l'inode existe-t-il toujours ? Où est-il ?), et le fichier de recherche inversée est muté ou régénéré, et les liens symboliques des balises sont mis à jour.
J'anticipe un cas délicat :que se passe-t-il si le fichier étiqueté n'est pas là 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 là où le fichier de recherche dit qu'il se trouve, le fichier de recherche étant hors de Date? Il y a plusieurs façons de gérer ce cas, aucune n'est évidemment idéale. En dehors de cela, toute cette tâche semble être le genre de choses auxquelles Perl est bien adapté...
Personne n'a mentionné, mais vous devriez certainement regarder les attributs étendus du système de fichiers.ext4 par exemple. il existe des outils getfattr et setfattr pour les gérer. Bien sûr, vous devrez écrire des scripts shell pour rechercher des fichiers marqués avec sometag. En ce qui concerne les questions mentionnées, toutes les réponses sont "Oui". Vous devez seulement tenir compte du fait que cela dépend du système de fichiers.