Quelle est la bonne solution pour le marquage de fichiers sous Linux?
Je cherchais un moyen de baliser mes fichiers et de les rechercher/les filtrer en fonction de ces balises.
Voici mes ( mises à jour ):
- tout fichier lisible par l'utilisateur peut être étiqueté librement
- un utilisateur peut rechercher des fichiers correspondant à une ou plusieurs balises
- les fichiers peuvent être déplacés sans perdre les tags précédemment associés
- le système peut être sauvegardé facilement
- aucune dépendance sur aucun environnement de bureau
- si une interface graphique est impliquée, il doit y avoir une solution de secours cli
J'espérais disposer d'un système de fichiers de base et d'un hackery coreutils pour gérer cela, mais je n'y avais pas encore pensé assez.
En attendant, je vais passer en revue les beagle et metatracker, qui ont été mentionnés ici, et voir comment ils se comportent.
Ok, Beagle a d’énormes dépendances de gnome, et tracker est correct, mais a encore des dépendances que je n’aime pas ...
Fait des recherches plus poussées, et la voie à suivre pourrait très bien être les attributs de fichier étendus .
C'est une solution native pour les systèmes de fichiers les plus récents, mais ils ne sont pas encore très bien supportés (la plupart des coreutils les détruisent par défaut, cp par exemple a besoin de l'indicateur -a pour les préserver). J'aimerais entendre des réflexions sur leur utilisation pendant que je m'essaie à quelques piratages moi-même, même si cela pourrait justifier une nouvelle question.
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 hackery Shell et en utilisant la variable standard locatedb:
- Chaque répertoire contenant au moins un fichier marqué 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 script locate-tag; il devrait s'agir de deux ou trois lignes, n'utilisant que la commande locate 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é autour de 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 déplacés librement, 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 rechercher les chemins qui ont un inode donné , nous pouvons le faire en ne perdant les balises que 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 - ce n’est pas vraiment difficile.
- pas de dépendances sur les environnements de bureau - aucune
- Si une interface graphique est impliquée, il doit y avoir une solution de repli - c'est là où 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 donner 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 l'être, le fichier de recherche inversée dit qu'il existe toujours, mais le fichier prodigue n'est pas à l'emplacement où le fichier de recherche l'indique, le fichier de recherche étant hors de rendez-vous amoureux? 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é ...
Je viens de publier un alpha de mon nouveau programme qui tente de fournir cette fonctionnalité. Il répond actuellement à certaines de vos exigences, mais pas à toutes. Cela pourrait vous intéresser de toute façon. Il fournit un outil de ligne de commande pour le marquage et un système de fichiers virtuel pour la navigation (les balises sont représentées par des répertoires).
tout fichier lisible par l'utilisateur peut être étiqueté 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 tags précédemment associés
Non. Cependant, l’application stocke les empreintes digitales des fichiers marqués, qui sont utilisées pour identifier les fichiers déplacés. Une commande 'réparation' est fournie pour mettre à jour les chemins des fichiers déplacés. (Évidemment, ce mécanisme échoue si un fichier est à la fois déplacé et modifié.)
le système peut ê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 tout programme prenant en charge les liens symboliques.
si une interface graphique est impliquée, il doit y avoir une solution de secours cli
Pas d'interface graphique à l'heure actuelle.
Je suis surpris que personne n'ait mentionné TagSpaces . Il répond à toutes vos exigences car les balises sont stockées dans le nom de fichier et que TagSpaces est multi-plateforme.
Je pense que cela pourrait répondre à toutes vos exigences. En tout cas, c'est un morceau de code sympa:
http://pages.stern.nyu.edu/~marriaga/software/oyepa
L’interface graphique nécessite Qt, mais il existe une application de ligne de commande pour la recherche et le fait que toutes les balises soient réellement dans le nom du fichier facilite la manipulation des balises | fichiers de la cli.
Personne n'a mentionné, mais vous devriez absolument regarder les attributs de système de fichiers étendus. ext4 par exemple les a. 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 prendre en compte que cela dépend du système de fichiers.
Vous n'avez probablement pas besoin d'installer le bureau KDE complet pour leur bibliothèque de marquage, Nepomuk. Vous devrez toujours installer les bibliothèques de base KDE, cependant ...
Quelques autres alternatives pourraient être tagasistant , tagfs ou dantalien .
Cet article récent sur les outils de recherche de bureau de Linux indique que Tracker prend en charge le balisage. Malheureusement, il est supposé être à moitié cassé dans l'ancienne version testée. Peut-être que c'est corrigé maintenant?
- Pas à l'échelle du système.
- Vous pouvez le sauvegarder.
- Il est livré avec Gnome.
Donc, vous ne trouverez pas d’intégration Nepomuk dans gnome, en ligne de commande ou ailleurs dans Linux.
Inversement, avec Tracker, vous ne trouverez pas d’intégration kde autant que je sache. Pas sûr sur CLI.
Donc, malheureusement, la réponse semble être "non".
Encore plus malheureusement, cela ne signifie pas qu'il y ait une bonne opportunité pour en construire une non plus. Les utilitaires de ligne de commande Linux n'ont pas beaucoup de points communs avec le gestionnaire de fichiers GUI, par exemple, il n'y a donc aucun composant commun qui pourrait être étendu pour prendre en charge le concept.
J'ai créé un petit programme qui utilise SQLite à cette fin. Cela a résolu mon besoin, mais peut-être que ça vous aide aussi:
https://github.com/alvatar/dfym
Le seul problème avec cette approche est qu'il ne se synchronise pas avec les déplacements et les suppressions, mais qu'il résout le problème pour les fichiers relativement statiques.
TMSU est un outil pour marquer vos fichiers. Il fournit un simple utilitaire de ligne de commande pour l’application de balises et un système de fichiers virtuel pour vous donner une vue de vos fichiers à partir de balises à partir de tout autre programme.
TMSU ne modifie en aucune manière vos fichiers: ils restent inchangés sur le disque ou sur le réseau, où que vous soyez. TMSU maintient sa propre base de données et vous obtenez simplement une vue supplémentaire, que vous pouvez monter où bon vous semble, en fonction des balises que vous avez configurées.
Surpris, personne n'en a parlé.