Non è chiaro quale tipo di ricerca desideri. Se vuoi che funzioni ovunque in unix, piuttosto che solo la tua home directory, e vuoi solo fare ricerche basate sul nome percorso, il seguente schema è fattibile, con un po 'di hacking della shell e usando lo standard locatedb:
- Ogni directory che contiene almeno un file con tag necessita di una sottodirectory standard, diciamo
.path-tags;
- Ogni file nella directory $ FILE con collegamento $ TAG (che non deve contenere il carattere
_) ha un collegamento$TAG_$FILE -> ../$FILE
Vi lascio i dettagli della locate-tagsceneggiatura; dovrebbe essere una linea a due o tre locaterighe , usando solo il comando e la pirateria informatica. (Se sei interessato, potrei scriverne uno).
Alcuni tipi di KDE hanno parlato di questo tipo di schema per i metadati, anche se non ricordo i dettagli.
Dovrebbe anche essere possibile eseguire test più sofisticati, che esaminano il contenuto, basati su questo schema con uno script simile find.
Considerazioni sui requisiti aggiornati
- qualsiasi file leggibile dall'utente può essere taggato liberamente - Sì, non dovrebbe essere un problema
- un utente può cercare file corrispondenti a uno o più tag - Allo stesso modo
- i file possono essere spostati senza perdere i tag precedentemente associati - Le directory in cui si trovano possono essere spostate liberamente, ma se il file viene spostato dalla directory, ci sono problemi. Se i tag hanno preso la forma
$TAG_$INODE_$FILEe abbiamo un modo efficiente per trovare quali percorsi hanno un dato inode , allora possiamo farlo, perdendo i tag solo se usciamo dai filesystem. La copia dei file potrebbe creare qualche problema, e questo è chiaramente più complicato del mio suggerimento originale.
- è possibile eseguire facilmente il backup del sistema , non sostanzialmente difficile.
- nessuna dipendenza da alcun ambiente desktop - nessuna
- se è coinvolta qualche gui, ci deve essere un fallback cli - è lì che viviamo!
Postscript
Il file "reverse-inode-lookup" descritto dal link (2) che mi hai mostrato nella tua risposta a (1) può essere usato per fornire un'infrastruttura aggiuntiva. Possiamo eseguire un servizio sul file di ricerca inversa, che verifica che ciascun inode indicato nel nome file di un tag corrisponda all'inode del file (se presente) a cui punta il tag. Se non esiste alcuna corrispondenza, è possibile eseguire l'intervento chirurgico richiesto (esiste ancora l'inode? Dov'è?) E il file di ricerca inversa viene modificato o rigenerato e il collegamento simbolico dei tag viene aggiornato.
Prevedo un caso complicato: cosa succede se il file taggato non è dove i tag dicono che dovrebbe essere, il file di ricerca inversa dice che esiste ancora, ma il file prodigo non è dove dice il file di ricerca, il file di ricerca essendo fuori Data? Ci sono alcuni modi per gestire questo caso, nessuno ovviamente ideale. A parte questo, l'intero compito sembra essere il tipo di cosa che Perl è adatto a ...
