mdfind
consults the Spotlight database in order to provide search results faster than scanning the whole file system for each query.
mdls
on the other hand does not rely on the Spotlight database, as it doesn't need to scan the file system - you're specifying the file you want to examine directly. It does however rely on the Spotlight API in order to provide the data requested.
I.e. mdls
is not a program that contains code that tries to "parse" all sorts of file types or gather information information from many place. Nor does it directly look this up in the store.db
file.
When you request the metadata for a specific file through the Spotlight API, information is gathered from a number of places and given to the program (mdls
in this case) in a uniform format. These sources are for example:
- the file system meta data
- the extended attributes stored in the file system
- information from Application bundles and similar places
- information gathered by the Spotlight importer plugin for the specific file type
Note that some importer plugins are external - i.e. small programs stored seperately from Spotlight itself. For example in /System/Library/Spotlight
you'll typically find importers for things such as audio files, video files, compressed archives, etc. Similarly applications can come with their own Spotlight importers, stored in locations such as for example:
/Applications/Microsoft Outlook.app/Contents/Library/Spotlight/Microsoft Outlook Spotlight Importer.mdimporter
In this case for importing data from Outlook into Spotlight.
Other plugins are internal - i.e. they're selfcontained within Spotlight and do not require external programs. Your example in the question was for a .dmg
file, and the importer for those is internal.
You can run the importer for a specific file to see exactly what attributes it would have given to the Spotlight index - without actually changing the Spotlight index. Run a command like this:
mdimport -t -d2 ~/Downloads/MacVim.dmg
Note that -d2
means that you see all the imported metadata attributes, except for kMDItemTextContent
which in the case of a document would typically be very large and not preferable to see in a Terminal output. You can view that attribute as well by using the -d3
argument instead.
As these importers are effectively run as general purpose programs, the data sources for the importers themselves can be almost anything. I.e. it is not restricted to returning data found in the file system itself - it could even give attributes found by consulting cloud servers over the network (for example when you have a file stored in iCloud).