O que é uma boa solução para a marcação de arquivos no linux? [fechadas]

Question

Estou procurando uma maneira de marcar meus arquivos e pesquisá-los / filtrá-los com base nessas tags.

Aqui estão os meus requisitos ( atualizado ):

• qualquer arquivo legível pelo usuário pode ser marcado livremente
• um usuário pode pesquisar arquivos que correspondam a uma ou várias tags
• arquivos podem ser movidos sem perder as tags associadas anteriormente
• o sistema pode ser salvo em backup com facilidade
• sem dependências em qualquer ambiente de área de trabalho
• se algum gui estiver envolvido, deve haver um fallback cli

Eu tenho esperado por algum sistema de arquivos básico & hackery Coreutils para lidar com isso, mas eu não tenho pensado sobre isso com bastante dificuldade ainda.
Enquanto isso, revisarei o beagle e o metatracker, que foram mencionados aqui, e veja como eles se comportam.

Ok, então o beagle tem grandes dependências do gnome, e o tracker é ok, mas ainda tem algumas dependências que eu não gosto ...

Estamos fazendo mais pesquisas, e o caminho a percorrer pode muito bem ser atributos de arquivo estendidos .
Essa é uma solução nativa para os sistemas de arquivos mais recentes, mas eles ainda não são muito bem suportados (a maioria dos coreutils os destrói por padrão, por exemplo, o cp precisa do sinalizador -a para preservá-los). Gostaria de ouvir alguns pensamentos sobre como usá-los enquanto eu tento minha mão em alguns hacks, embora isso possa justificar uma nova pergunta.

    

Answer 1

Não está claro que tipo de pesquisa você deseja. Se você quer que ele funcione em qualquer lugar no unix, em vez de apenas em seu diretório home, e você só quer fazer buscas baseadas em pathname, o esquema a seguir é viável, com um pouco de hacker e usando o padrão locatedb :

1. Cada diretório que contém pelo menos um arquivo marcado precisa de um subdiretório padrão, digamos .path-tags ;
2. Cada arquivo no diretório $ FILE com o link $ TAG (que não deve conter o char _ ) tem um link $TAG_$FILE -> ../$FILE

Deixo os detalhes do script locate-tag para você; deve ser um dois ou três liner, usando apenas o comando locate e hackery de shell. (Se você estiver interessado, eu poderia escrever um).

Alguns dos caras do KDE falaram sobre esse tipo de esquema para metadados, embora eu não me lembre dos detalhes.

Também deve ser possível fazer testes mais sofisticados e de exame de conteúdo com base nesse esquema, com um script semelhante em torno de find .

Pensamentos sobre requisitos atualizados

1. qualquer arquivo legível pelo usuário pode ser marcado livremente - Sim, não deve haver problema
2. um usuário pode pesquisar por arquivos que correspondam a uma ou várias tags - Da mesma forma
3. arquivos podem ser movidos sem perder as tags associadas anteriormente - Os diretórios que eles habitam podem ser movidos livremente, mas se o arquivo for movido do diretório, estamos com problemas. Se as tags tivessem o formato $TAG_$INODE_$FILE e tivéssemos uma maneira eficiente de descobrir quais caminhos têm um determinado inode , então podemos fazer isso, perdendo tags apenas se sairmos dos sistemas de arquivos. Copiar arquivos pode causar alguns problemas, e isso é claramente mais complicado do que minha sugestão original.
4. o sistema pode ser facilmente armazenado em backup - não é essencialmente difícil.
5. sem dependências em qualquer ambiente de desktop - nenhum
6. Se algum gui estiver envolvido, deve haver um cli fallback - é onde vivemos!

Postscript O arquivo "reverse-inode-lookup" descrito pelo link (2) você me mostrou em sua resposta para (1) pode ser usado para fornecer alguma 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 algum) ao qual o tag aponta. Se não houver correspondência, a cirurgia necessária pode ser executada (o inode ainda existe? Onde está?) E o arquivo de pesquisa inversa está sendo mutado ou regenerado e os links simbólicos da tag sendo atualizados.

Eu antecipo um caso complicado: e se o arquivo marcado não estiver onde as tags dizem que deveria ser, o arquivo de pesquisa reversa diz que ele ainda existe, mas o arquivo pródigo não é onde o arquivo de pesquisa diz, é o arquivo de pesquisa estando desatualizado? Existem algumas maneiras de lidar com este caso, nenhuma obviamente ideal. Além disso, toda essa tarefa parece ser o tipo de coisa que Perl é bem adequado para ...

    

Answer 2

Acabei de lançar um alfa do meu novo programa que tenta fornecer essa funcionalidade. Atualmente, ele atende alguns requisitos, mas não todos. Pode ser de interesse para você de qualquer maneira. Ele fornece uma ferramenta de linha de comando para marcação e um sistema de arquivos virtual para navegação (onde tags são representadas por diretórios).

link

any file readable by the user can be tagged freely

Sim.

a user can search for files matching one or several tags

Sim. Através da ferramenta de linha de comando ou navegando pelos diretórios de tags no sistema de arquivos virtual.

files can be moved around without losing the previously associated tags

Não. No entanto, o aplicativo armazena as impressões digitais dos arquivos marcados que são usados para ajudar a identificar os arquivos movidos. Um comando 'repair' é fornecido para atualizar os caminhos dos arquivos movidos. (Obviamente, este mecanismo falha quando um arquivo é movido e modificado.)

the system could be backed up easily

Sim. É um simples arquivo de banco de dados do Sqlite 3.

no dependencies on any desktop environment

Sim. Sem dependências e como ele pode ser executado como um sistema de arquivos virtual, ele está disponível para uso como um sistema de arquivos em qualquer programa que suporte links simbólicos.

if any gui is involved, there must be a cli fallback

Sem GUI no momento.

    

Answer 3

Acho que isso pode atender a todos os seus requisitos. Em todo caso, é um código legal:

link

A GUI requer o Qt, mas há um aplicativo de linha de comando para pesquisa e o fato de que todas as tags estão realmente no nome do arquivo torna trivial manipular os arquivos de tags do CLI.

    

Answer 4

Você provavelmente não precisa instalar toda a área de trabalho do KDE para sua biblioteca de marcação, o Nepomuk. Você ainda teria que instalar as bibliotecas básicas do KDE, embora ...

    

Answer 5

Fiquei surpreso que ninguém mencionou TagSpaces . Ele atende a todos os seus requisitos porque as tags são armazenadas no nome do arquivo e o TagSpaces é de plataforma cruzada.

    

Answer 6

Ninguém mencionou, mas você definitivamente deve observar os atributos estendidos do sistema de arquivos. ext4 por exemplo os tem. Existem ferramentas getfattr e setfattr para lidar com elas. Claro que você terá que escrever alguns scripts de shell para procurar por arquivos marcados com alguma coisa. Em relação às questões mencionadas, todas as respostas são "sim". Você só deve levar em conta que depende do sistema de arquivos.

    

Answer 7

Este artigo recente sobre Ferramentas de pesquisa do ambiente de trabalho do Linux menciona que Tracker suporta marcação. Infelizmente, é suposto estar meio quebrado na versão antiga que eles testaram. Talvez esteja consertado agora?

1. Não é amplo no sistema.
2. Você pode fazer o backup.
3. É fornecido com o Gnome.

Answer 8

Tente Beagle . Eu acho que é muito bom.

Pode não atender a todos os requisitos, e não tenho certeza do que poderia. Por exemplo, os arquivos FIFO suportam atributos estendidos? Se não o fizerem, o Beagle tem um banco de dados de fallback.

    

Answer 9

Algumas outras alternativas podem ser tagasistant , tagfs ou dantalian .

    

Answer 10

Portanto, você não encontrará a integração do Nepomuk no gnome, na linha de comando ou em outro lugar no Linux.

Por outro lado, com o Tracker você não encontrará a integração do kde AFAIK. Não tenho certeza no CLI.

Então, infelizmente, a resposta parece ser "não".

Ainda mais infelizmente, isso não significa que há uma boa oportunidade aqui para construir um também. Os utilitários de linha de comando do Linux não têm muito em comum com o gerenciador de arquivos da GUI, por exemplo, então, arquitetonicamente, não há componentes comuns que possam ser estendidos para suportar o conceito.

    

Answer 11

Eu fiz um pequeno programa que usa o SQLite para esse propósito. Isso resolveu minha necessidade, mas talvez ajude você também:

link

O único problema com essa abordagem é que ela não sincroniza com movimentos e exclusões, mas resolve o problema de arquivos relativamente estáticos.

    

Answer 12

TMSU

TMSU is a tool for tagging your files. It provides a simple command-line utility for applying tags and a virtual filesystem to give you a tag-based view of your files from any other program.

TMSU does not alter your files in any way: they remain unchanged on disk, or on the network, wherever your put them. TMSU maintains its own database and you simply gain an additional view, which you can mount where you like, based upon the tags you set up.

Surpreso, ninguém mencionou isso.

    

Answer 13

Eu sugiro dar uma olhada em um sistema de controle de versão como o Subversion para esses tipos de recursos acima e além do sistema de arquivos. Alguns podem ser mais adequados para você do que outros, mas geralmente:

• Muitas tags de suporte (certamente subversão).
• Muitos são de plataforma cruzada; Windows, Mac, Linux, praticamente todos os Unixes.
• Muitos têm front-ends de GUI e clientes de linha de comando.
• Muitos já têm ligações para sua linguagem de programação / script favorita.
• Muitos são facilmente salvos em backup.
• Muitos são projetados para serem facilmente compartilháveis de uma forma ou de outra.
• Muitos permitem controlar o acesso.
• Você não precisa reinventar a roda.
  • Você aprende e usa comandos / ferramentas padrão já usados por milhões.
• Você pode instalá-lo hoje para o seu repositório de SO favorito; apt-get install, yum instalar
• Você também obtém o gerenciamento de versões "gratuitamente".

Um exemplo cli com o Subversion: ~/svn/atestrepository: $ svn propset mytag "something" dir1 property 'mytag' set on 'dir1' $ svn propset myothertag "nothing" dir1/file1 property 'myothertag' set on 'dir1/file1' $ svn propset anemptytag "" dir1/file2 property 'anemptytag' set on 'dir1/file2'

$ svn propget -R mytag dir1 - algo ~ / svn / atestrepository: $ svn propget -R myothertag dir1 / file1 - nada $ svn propget -R anemptytag dir1 / file2 - $ svn proplist dir1 / file2 Propriedades em 'dir1 / file2':   anemptytag   svn: palavras-chave

Eu não recomendaria essas ferramentas para grandes arquivos binários (em tamanho gigabyte) que mudam regularmente, mas para todo o resto elas já são bem comprovadas e dimensionadas para tamanhos muito grandes.