Diferentes valores de metadados kMDItemKind do Spotlight para o mesmo arquivo em unidades diferentes

Question

Eu me deparei com um problema em que acho que o mesmo arquivo de vídeo tem valores diferentes para os metadados kMDItemkind Spotlight dependendo da unidade em que ele reside (mesma máquina, é claro), o que faz buscas no Spotlight no arquivo. Tipo falha. Para agravar o problema, o valor na unidade externa é, em alguns casos, incorreto e inconsistente com a hierarquia de tipo de documento fornecida pelo aplicativo de onde vem.

• Na unidade interna ,
  1. para um arquivo de vídeo do Matroska ( mkv file extension), mdls lists kMDItemKind como “Video Media”. Isso está correto, já que é o player padrão desse tipo de arquivo ( MPlayerX ) tipo de vídeo “tamanho único”.
  2. para um arquivo QuickTime MPEG4 da iTunes Store ( m4v extensão), mdls listas kMDItemKind como “Apple MPEG-4-Film”. Novamente, isso está correto, já que é o tipo de mídia de vídeo correspondente do tipo de arquivo padrão (QuickTimeX).
• Na minha unidade FireWire externa ,
  1. para o mesmo arquivo Matroska, mdls lists kMDItemKind como "Movie-DivX". Isso é obviamente incorreto, mas também é incorreto mesmo para iFlicks , que fornece esse valor, pois a hierarquia de tipo de documento do iFlicks não liga mkv para este tipo - liga-se a “Video-Matroska”.
  2. para o mesmo arquivo MPEG4, mdls lists kMDItemKind como “Video-MPEG4”. Isso é tecnicamente correto, mas, novamente, é um valor fornecido pelo iFlicks, que não é o player padrão para esse tipo de arquivo, nem o player designado no Finder.
• Em ambas as unidades , a janela "Obter Informações" do Finder mostra o tipo de arquivo correto (ou seja, "Mídia de Vídeo" / "MPEG-4-Filme da Apple"), mas de forma consistente com os valores kMDItemKind As pesquisas do Spotlight nesse tipo retornam apenas um resultado na unidade interna.

A diferença na saída de mdls nos respectivos arquivos mostra que, além dessa diferença, as únicas outras chaves que diferem são kMDItemFSOwnerGroupID e kMDItemFSOwnerGroupID , que são definidas como 99 ( _unknown ) na unidade externa e para meus IDs de usuário e grupo no interno (note que, apesar do que isso sugere, a propriedade e as permissões reais dos arquivos são idênticas).

Ambas as unidades são formatadas como Mac OS Extended Journaled , mas o problema é idêntico quando copio o arquivo em questão em uma chave USB formatada em FAT32. Copiar, duplicar ou mover arquivos pela unidade não altera esse fenômeno, apenas transferindo de interno para externo e vice-versa .

Por fim, indexar novamente a unidade externa (usando sudo mdutil -E "/Volumes/My Book" , primeiro e depois da maneira mais difícil, desativando primeiro a indexação, excluindo .Spotlight-V100 , fazendo o acima e reativando a indexação) não faz diferença. O registro de data e hora dos metadados é alterado, mas os valores permanecem os mesmos.

Como faço para que o Spotlight armazene o valor correto de kMDItemKind dos meus arquivos de vídeo, conforme definido pelos respectivos players padrão, no disco externo?

Execução do OS X 10.7.4 (problema presente no 10.7.3 já), alemão. Outros aplicativos de mídia instalados (além do MPlayerX e iFlicks): Subler, MediaInfo, Perian

    

Answer 1

Acontece que as chaves kMDItemFSOwner*ID que estão sendo definidas para _unknown apontaram na direção certa: a atual implementação do Spotlight do Lion aparentemente define kMDItemKind para valores tangencialmente relacionados aos corretos em arquivos e pastas cujo proprietário e / ou grupo são 99 (também conhecido como _unknown ). O problema com isso é que os discos externos são definidos, por padrão, para ignorar a propriedade de seu conteúdo ou, em termos técnicos, seu status DB é definido para desativar (“negar”) a propriedade em disco.

Nesse caso, a propriedade e a propriedade do grupo de todo o conteúdo do volume são definidas como _unknown ( 99 ), mas isso dificulta o reconhecimento do problema, tanto o Finder quanto o shell exibirão o grupo de usuários atual. e o ID do usuário, em vez desses valores ( sudo ls -lna mostrará os valores corretos - indique o @kpatten em este tópico da Comunidade de suporte da Apple ).

Solução

1. ativa (adota) a propriedade em disco para o volume. Isso pode ser feito através da caixa de diálogo "Obter Informações" de um volume no Finder (desmarque a caixa de seleção mais abaixo) ou através do shell:

   sudo vsdbutil -a /Volumes/<Volume name>
   

2. Assuma a propriedade de todos os arquivos e pastas afetados. Eu recomendaria deixar a raiz do volume sozinha (afinal, a predefinição da Apple faz sentido - você não quer que uma unidade removível seja vinculada à estrutura de propriedade do Mac com a qual ela está conectada, pelo menos não muito profundamente) e fazendo isso no nível das principais pastas que contêm o conteúdo afetado:

   sudo chown -R $(id -u "$USER"):$(id -g "$USER") /Volumes/<Volume name>/<Folder>
   

3. re-indexe o volume

   sudo mdutil -E /Volumes/<Volume name>
   

A verificação com mdls após essas etapas mostrará corretamente kMDItemFSOwner*ID keys (não é uma surpresa) e - mais precisamente - um valor correto de kMDItemKind para os arquivos.

Caveat Empteor: este é um hack para contornar o problema - não uma solução (que teria de ser fornecida pela Apple). Um deles, subverte a “remoção” de uma unidade externa, pois define permissões que só são válidas quando conectadas a um Mac específico para todos os arquivos e pastas criados / copiados na hierarquia de redefinição. Dois, ele só funciona em volumes com um sistema de arquivos que pode definir propriedades POSIX - os dados do Spotlight em outros volumes (digamos, os formatados em FAT32) não podem ser corrigidos dessa forma.

Bug reportado para a Apple. Espelhado como Radar aberto # 1725402 .

Referências

• vsdbutil man page
• “Ignorar propriedade neste volume, desmarcada, ainda ignora a propriedade”