Não está claro que tipo de pesquisa você deseja. Se você deseja que ele funcione em qualquer lugar do unix, e não apenas no seu diretório pessoal, e você deseja apenas fazer pesquisas com base no nome do caminho, o seguinte esquema é viável, com um pouco de hackeamento de shell e usando o padrão locatedb:
- Cada diretório que contém pelo menos um arquivo marcado precisa de um subdiretório padrão, digamos
.path-tags;
- Cada arquivo no diretório $ FILE com o link $ TAG (que não deve conter o caractere
_) possui um link$TAG_$FILE -> ../$FILE
Deixo os detalhes do locate-tagscript para você; deve ser de duas ou três linhas, usando apenas o locatehackery de comando e shell. (Se você estiver interessado, eu poderia escrever um).
Alguns membros do KDE conversaram sobre esse tipo de esquema de metadados, embora eu não me lembre dos detalhes.
Também deve ser possível fazer testes mais sofisticados para examinar o conteúdo com base nesse esquema, com um script semelhante find.
Reflexões sobre requisitos atualizados
- qualquer arquivo legível pelo usuário pode ser marcado livremente - Sim, não deve ser problema
- um usuário pode procurar por arquivos que correspondam a uma ou várias tags - Da mesma forma
- os arquivos podem ser movidos sem perder as tags associadas anteriormente - Os diretórios em que eles habitam podem ser movidos livremente, mas se o arquivo for movido do diretório, estamos com problemas. Se as tags
$TAG_$INODE_$FILEtiverem o formato e tivermos uma maneira eficiente de descobrir quais caminhos têm um determinado inode , podemos fazer isso, perdendo as tags apenas se sairmos dos sistemas de arquivos. A cópia de arquivos pode causar alguns problemas, e isso é claramente mais complicado do que minha sugestão original.
- o backup do sistema pode ser feito facilmente - não é difícil.
- sem dependências em nenhum ambiente de desktop - nenhum
- se qualquer gui estiver envolvido, deve haver um retorno do cli - é onde moramos!
Postscript
O arquivo "pesquisa de inode reversa" descrito pelo link (2) que você me mostrou em sua resposta a (1) pode ser usado para fornecer uma infraestrutura adicional. Podemos executar um serviço no arquivo de pesquisa inversa, que verifica se cada inode fornecido no nome do arquivo de uma tag corresponde ao inode do arquivo (se houver) para o qual a tag aponta. Se não houver correspondência, a cirurgia necessária poderá ser executada (o inode ainda existe? Onde está?), E o arquivo de pesquisa inversa será mutado ou regenerado e os links simbólicos da tag serão atualizados.
Antecipo um caso complicado: e se o arquivo marcado não estiver onde as tags dizem que deveria estar, o arquivo de pesquisa inversa diz que ainda existe, mas o arquivo pródigo não está onde o arquivo de pesquisa diz que está, o arquivo de pesquisa está fora de encontro? Existem algumas maneiras de lidar com esse caso, nenhuma obviamente ideal. Além disso, toda essa tarefa parece ser o tipo de coisa para a qual Perl é adequado ...
