No está claro qué tipo de búsqueda desea. Si desea que funcione en cualquier lugar de Unix, en lugar de solo su directorio de inicio, y solo desea realizar búsquedas basadas en el nombre de ruta, el siguiente esquema es viable, con un poco de piratería de shell y utilizando el estándar locatedb:
- Cada directorio que contiene al menos un archivo etiquetado necesita un subdirectorio estándar, por ejemplo
.path-tags;
- Cada archivo en el directorio $ FILE con enlace $ TAG (que no debe contener el carácter
_) tiene un enlace$TAG_$FILE -> ../$FILE
Te dejo los detalles del locate-tagguión; debe ser de dos o tres líneas, utilizando solo el locatecomando y la piratería de shell. (Si está interesado, podría escribir uno).
Algunos de los tipos de KDE hablaron sobre este tipo de esquema para metadatos, aunque no recuerdo los detalles.
También debería ser posible realizar pruebas de examen de contenido más sofisticadas basadas en este esquema con un script similar envuelto find.
Reflexiones sobre requisitos actualizados
- cualquier archivo legible por el usuario puede ser etiquetado libremente - Sí, no debería ser un problema
- un usuario puede buscar archivos que coincidan con una o varias etiquetas , del mismo modo
- los archivos se pueden mover sin perder las etiquetas asociadas anteriormente : los directorios que habitan se pueden mover libremente, pero si el archivo se mueve desde el directorio, estamos en problemas. Si las etiquetas tomaron la forma
$TAG_$INODE_$FILEy tenemos una manera eficiente de encontrar qué rutas tienen un inodo dado , entonces podemos hacer esto, perdiendo etiquetas solo si salimos de los sistemas de archivos. Copiar archivos puede causar algunos problemas, y esto es claramente más complicado que mi sugerencia original.
- el sistema podría ser respaldado fácilmente , no esencialmente difícil.
- sin dependencias en ningún entorno de escritorio : ninguno
- si hay alguna interfaz gráfica de usuario involucrada, debe haber un retroceso de cli : ¡ahí es donde vivimos!
Postdata
El archivo "búsqueda de inodo inverso" descrito por el enlace (2) que me mostró en su respuesta a (1) se puede utilizar para proporcionar una infraestructura adicional. Podemos ejecutar un servicio en el archivo de búsqueda inversa, que verifica que cada inodo dado en el nombre de archivo de una etiqueta coincida con el inodo del archivo (si corresponde) al que apunta la etiqueta. Si no hay coincidencia, entonces se puede realizar la cirugía requerida (¿el inodo todavía existe? ¿Dónde está?), Y el archivo de búsqueda inversa está mutado o regenerado, y los enlaces simbólicos de la etiqueta se actualizan.
Anticipo un caso complicado: qué pasa si el archivo etiquetado no está donde las etiquetas dicen que debería estar, el archivo de búsqueda inversa dice que todavía existe, pero el archivo pródigo no está donde dice el archivo de búsqueda, el archivo de búsqueda está fuera de ¿fecha? Hay algunas formas de manejar este caso, ninguna obviamente ideal. Aparte de esto, toda esta tarea parece ser el tipo de cosas para las que Perl es ideal ...
