Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have run into an issue where I find the same video file to have different values for the kMDItemkind Spotlight metadata depending on the drive it resides on (same machine, of course), which makes Spotlight searches on the file “Kind” fail. To compound the issue, the value on the external drive is in some cases incorrect and inconsistent with the document type hierarchy provided by the application it comes from.

  • On the internal drive,
    1. for a Matroska video file (mkv file extension), mdls lists kMDItemKind as “Video Media”. This is correct, as it is the default player’s for this file type (MPlayerX) “one size fits all” video type.
    2. for a QuickTime MPEG4 file from the iTunes Store (m4v extension), mdls lists kMDItemKind as “Apple MPEG-4-Film”. Again, this is correct, as it is the default player’s for this file type (QuickTimeX) matching video media type.
  • On my external FireWire drive,
    1. for the same Matroska file, mdls lists kMDItemKind as “Movie-DivX”. This is obviously incorrect, but it is also incorrect even for iFlicks, which provides this value, as iFlicks’ document type hierarchy does not bind mkv to this type – it binds it to “Video-Matroska”.
    2. for the same MPEG4 file, mdls lists kMDItemKind as “Video-MPEG4”. This is technically correct, but again, it is a value provided by iFlicks, which is neither the default player for this file type, nor the assigned player in Finder.
  • On both drives, the Finder “Get Info” window shows the correct file kind (i.e. “Video Media” / “Apple MPEG-4-Film”), but, consistently with the kMDItemKind values, Spotlight searches on this kind only return a result on the internal drive.

Diffing the output of mdls on the respective files shows that besides this difference, the only other keys differing are the kMDItemFSOwnerGroupID and kMDItemFSOwnerGroupID ones, which are set to 99 (_unknown) on the external drive, and to my user and group IDs in the internal one (note that despite what this suggests, actual file ownership and permissions are identical).

Both drives are formatted as Mac OS Extended Journaled, but the issue is identical when I copy the file in question on a FAT32 formatted USB key. Copying, duplicating or moving files around on the drive does not change this phenomenon, only transferring from internal to external and vice-versa does.

Finally, re-indexing the external drive (using sudo mdutil -E "/Volumes/My Book", first, then the hard way, by turning indexing off first, deleting .Spotlight-V100, doing the above and re-enabling indexing) does not make a difference. The time stamp of the metadata changes, but the values remain the same.

How do I get Spotlight to store the correct value for kMDItemKind of my video files, as defined by the respective default players, on the external drive?

Running OS X 10.7.4 (issue present in 10.7.3 already), German. Other installed media apps (besides MPlayerX and iFlicks): Subler, MediaInfo, Perian

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

As it turns out, the kMDItemFSOwner*ID keys being set to _unknown pointed in the right direction: Lion’s current Spotlight implementation apparently sets kMDItemKind to values only tangentially related to the correct ones on files and folders whose owner and / or group are 99 (aka _unknown). The problem with this is that external disks are set, by default, to ignore ownership of their contents, or, in technical terms, their status DB is set to deactivate (“disown”) on-disk ownership.

In this case, both ownership and group ownership of all volume contents is set to _unknown (99), but, and this makes the issue difficult to recognize, both Finder and the shell will display the current’s user group and user ID instead of these values (sudo ls -lna will show the correct values – hat tip to @kpatten on this Apple Support Communities thread).

Solution

  1. activate (“adopt”) on-disk ownership for the volume. This can be done through the “Get Info” dialog of a volume in Finder (untick the bottom-most checkbox) or via the shell:

    sudo vsdbutil -a /Volumes/<Volume name>
    
  2. take ownership of all files and folders affected. I’d recommend leaving the volume root alone (after all, Apple’s preset makes sense – you don’t want a removable drive to be bound to the ownership structure of the Mac it happens to be connected with, at least not too deeply) and doing this at the level of the top folders containing the affected content:

    sudo chown -R $(id -u "$USER"):$(id -g "$USER") /Volumes/<Volume name>/<Folder>
    
  3. re-index the volume

    sudo mdutil -E /Volumes/<Volume name>
    

Checking with mdls after these steps will show correctly set kMDItemFSOwner*ID keys (not a surprise) and – more to the point – a correct kMDItemKind value for the files.

Caveat Empteor: this is a hack to work around the issue – not a solution (which would have to be provided by Apple). One, it subverts the “removability” of an external drive, as it sets permissions that are only valid when connected to a specific Mac for all files and folders created / copied into the reset hierarchy. Two, it only works on volumes with a filesystem that can set POSIX ownerships – Spotlight data on other volumes (say, FAT32 formatted ones) cannot be fixed this way.

Bug reported to Apple. Mirrored as Open Radar #1725402.

References

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.