Unterschiedliche Spotlight kMDItemKind-Metadatenwerte für dieselbe Datei auf verschiedenen Laufwerken

Ich bin auf ein Problem gestoßen, bei dem ich finde, dass dieselbe Videodatei unterschiedliche Werte für die hat kMDItemkind Spotlight-Metadaten in Abhängigkeit von dem Laufwerk, auf dem sie sich befinden (natürlich auf demselben Computer), wodurch die Spotlight-Suche nach der Datei „Kind“ fehlschlägt. Um das Problem zu beheben, ist der Wert auf dem externen Laufwerk in einigen Fällen falsch und stimmt nicht mit der Dokumenttyphierarchie überein, die von der Anwendung bereitgestellt wird, von der es stammt.

Auf dem internen Laufwerk ,
1. für eine Matroska-Videodatei ( mkv Dateierweiterung), mdls Listen kMDItemKind als "Videomedien". Dies ist korrekt, da dies der Standard-Player für diesen Dateityp ist ( MPlayerX ) Videotyp "one size fits all".
2. für eine QuickTime MPEG4-Datei aus dem iTunes Store ( m4v Erweiterung), mdls Listen kMDItemKind als "Apple MPEG-4-Film". Auch dies ist korrekt, da dies der Standardplayer für diesen Dateityp (QuickTimeX) ist, der dem Medientyp des Videos entspricht.
Auf meinem externen FireWire-Laufwerk ,
1. für die gleiche Matroska-Datei, mdls Listen kMDItemKind als "Movie-DivX". Dies ist offensichtlich falsch, aber es ist auch falsch, auch für iFlicks , der diesen Wert liefert, da die Dokumenttyphierarchie von iFlicks nicht bindet mkv zu diesem Typ - es bindet es an "Video-Matroska".
2. für die gleiche MPEG4-Datei, mdls Listen kMDItemKind als "Video-MPEG4". Dies ist technisch korrekt, aber es handelt sich auch hier um einen von iFlicks bereitgestellten Wert, der weder der Standardplayer für diesen Dateityp noch der im Finder zugewiesene Player ist.
Auf beiden Laufwerken Im Finder-Fenster „Get Info“ wird der richtige Dateityp (d. h. „Video Media“ / „Apple MPEG-4-Film“) angezeigt, der jedoch mit dem übereinstimmt kMDItemKind Bei solchen Spotlight-Suchvorgängen wird nur ein Ergebnis auf dem internen Laufwerk zurückgegeben.

Diffing die Ausgabe von mdls auf den jeweiligen Dateien zeigt, dass neben diesem Unterschied die einzigen anderen Schlüssel, die sich unterscheiden, die sind kMDItemFSOwnerGroupID und kMDItemFSOwnerGroupID diejenigen, die auf 99 gesetzt sind ( _unknown ) auf dem externen Laufwerk und meinen Benutzer- und Gruppen-IDs auf dem internen Laufwerk (beachten Sie, dass der tatsächliche Dateibesitz und die Berechtigungen trotz dieser Hinweise identisch sind).

Beide Laufwerke sind formatiert als Mac OS Extended Journaled , aber das Problem ist identisch, wenn ich die betreffende Datei auf einen FAT32-formatierten USB-Stick kopiere. Durch Kopieren, Duplizieren oder Verschieben von Dateien auf dem Laufwerk wird dieses Phänomen nicht geändert, sondern nur von intern nach extern und übertragen und umgekehrt tut.

Zum Schluss das externe Laufwerk neu indizieren (mit sudo mdutil -E "/Volumes/My Book", zuerst, dann auf die harte Tour, indem Sie zuerst die Indizierung ausschalten, löschen .Spotlight-V100Dies zu tun und die Indizierung wieder zu aktivieren, macht keinen Unterschied. Der Zeitstempel der Metadaten ändert sich, aber die Werte bleiben gleich.

Wie kann ich Spotlight veranlassen, den korrekten Wert für zu speichern? kMDItemKind meiner Videodateien, wie von den jeweiligen Standardplayern definiert, auf dem externen Laufwerk?

Ausführen von OS X 10.7.4 (Problem bereits in 10.7.3 vorhanden), Deutsch. Andere installierte Medien-Apps (neben MPlayerX und iFlicks): Subler, MediaInfo, Perian

— kopischke
quelle

Wie sich herausstellt, die kMDItemFSOwner*ID Tasten auf _unknown in die richtige Richtung: Die aktuelle Spotlight-Implementierung von Lion scheint kMDItemKind auf Werte, die sich nur tangential auf die richtigen Werte in Dateien und Ordnern beziehen, deren Eigentümer und / oder Gruppe 99 (aka _unknown ). Das Problem dabei ist, dass externe Datenträger standardmäßig so eingestellt sind, dass sie den Besitz ihrer Inhalte ignorieren, oder dass der Status-DB so eingestellt ist, dass der Besitz der Datenträger deaktiviert wird („nicht verfügbar“).

In diesem Fall wird sowohl das Eigentumsrecht als auch das Gruppeneigentum an allen Volume-Inhalten auf festgelegt _unknown ( 99 ), aber, und dies macht das Problem schwer zu erkennen, werden sowohl Finder als auch die Shell die aktuelle Benutzergruppe und Benutzer-ID anstelle dieser Werte anzeigen ( sudo ls -lna zeigt die korrekten Werte an - Hut tipp auf @kpatten an Dieser Apple Support Communities-Thread ).

Lösung

Aktivieren ("Übernehmen") des Festplattenbesitzes für das Volume. Dies kann über das Dialogfeld "Get Info" eines Volumes im Finder (deaktivieren Sie das unterste Kontrollkästchen) oder über die Shell erfolgen:
```
sudo vsdbutil -a /Volumes/<Volume name>
```
Übernehmen Sie den Besitz aller betroffenen Dateien und Ordner. Ich würde empfehlen, das Volume-Stammverzeichnis in Ruhe zu lassen (schließlich ist Apples Voreinstellung sinnvoll - Sie möchten nicht, dass ein Wechseldatenträger an die Eigentumsstruktur des Mac gebunden ist, mit dem er verbunden ist, zumindest nicht zu tief) und Gehen Sie dazu auf der Ebene der obersten Ordner vor, die den betroffenen Inhalt enthalten:
```
sudo chown -R $(id -u "$USER"):$(id -g "$USER") /Volumes/<Volume name>/<Folder>
```
Indizieren Sie das Volume neu
```
sudo mdutil -E /Volumes/<Volume name>
```

Überprüfung mit mdls Nach diesen Schritten wird richtig eingestellt angezeigt kMDItemFSOwner*ID Schlüssel (keine Überraschung) und - genauer gesagt - ein korrekter kMDItemKind Wert für die Dateien.

Vorbehalt Emptor: Dies ist ein Hack, um das Problem zu umgehen - keine Lösung (die von Apple bereitgestellt werden müsste). Zum einen wird die "Entfernbarkeit" eines externen Laufwerks untergraben, da Berechtigungen festgelegt werden, die nur gültig sind, wenn eine Verbindung zu einem bestimmten Mac für alle Dateien und Ordner besteht, die in der Zurücksetzungshierarchie erstellt / kopiert wurden. Zweitens funktioniert es nur auf Volumes mit einem Dateisystem, das POSIX-Eigentumsrechte festlegen kann. Spotlight-Daten auf anderen Volumes (z. B. FAT32-formatierte) können nicht auf diese Weise repariert werden.

Fehler bei Apple gemeldet. Gespiegelt als Öffnen Sie Radar Nr. 1725402 .

Verweise

— kopischke
quelle