I hadn't seen the actual error messages when I posted my previous comment. I can now provide more info.
What's happening is that Spotlight is indexing the drive. The metadata that it collects from the contents of a file depends on what kind of file it is. (For example, it might collect words from a PDF file, but a PDF file contains formatting information as well as text, and it's only the text that should be indexed. EXIF data from a photograph should be extracted and saved, but there's no text, even if by some wild coincidence the binary representation of the pixels of an image happened to spell out a word.)
To support the wild range of file formats that need to be indexed, there is an MDImporter plugin for each file type. An application that has its own custom file format will typically provide its own MDImporter for that file format. This relieves Spotlight itself from the responsibility of understand every proprietary file format in the world, many of which haven't even been defined yet.
Spotlight also has to be cognizant of security. It cannot tell one user about the content of another user's files. For security purposes, it uses the following division of labor:
There is a background process called mds
which runs as root and is responsible for updating the spotlight index. But root is much too powerful to be turned loose running MDImporters for file formats it doesn't understand. Can root really trust an MDImporter supplied by some random developer?
spans a subprocess called mdworker
. There is a copy of mdworker
running as user "_spotlight". This user doesn't own any files and is not in any groups, so it can read only files that are readable by everyone. This copy of mdworker
collects whatever information is publicly available and can be reported to everyone.
finds a file owned by a particular user, it also spawns a copy of mdworker
running as that user. That copy of mdworker
collects everything that that user can see. If you look in Activity Monitor at any time, you'll often see several copies of mdworker
running, each as a different user.
All copies of mdworker
report what they find back to mds
, which puts the data in the spotlight index, tagged with which user found it. When a user later queries Spotlight, it returns only the data that that user could have seen on their own.
Each copy of mdworker
looks at every file it can read that hasn't yet been indexed, figures out what type of file it is, and invokes the appropriate MDImporter. It's up to the MDImporter to make sense of the file, and report anything interesting back to mdworker
With that background, your error messages can be readily explained.mds
spun off mdworker
found a file "Berthold Script" buried in a "Sent Mail ..." mailbox. Apparently you had sent this file as an attachment to someone, and then backed up your Sent Mail mailbox (with its attachments) to No Noodles.mdworker
decided this attachment was a font file, and invoked an MDImporter named FontImporter
to analyze it. FontImporter
thinks the file is corrupted, and is generating several error messages.
An MDImporter such as FontImporter
sends whatever information it gleans back to mdworker
through a "pipe", which you can think of as an in-RAM file that never actually goes to disk. One process (FontImporter
) writes data into one end of the pipe, another process (mdworker
) reads from the other end. When FontImporter
determined the file was corrupted, it abruptly stopped writing to the pipe. This confused mdworker
, which thought more data would be coming down the pipe and got an EOF error trying to read it.
What it boils down to is that you have two problems. The first is that you have a corrupted font file (or a file that isn't actually a font file but mdworker
thinks it is). The second is that whoever wrote the FontImporter
plugin (probably Apple) didn't thoroughly test what it does when confronting a corrupted file.
The first problem can be solved by deleting the corrupted font file (or modifying it so it no longer looks like a font file).
The second problem is Apple's. You should file a bug report telling them that FontImporter does not properly recover from corrupted fonts. This is the sort of bug that Apple will likely never be aware of, and cannot fix, until someone reports it. Nor is it the sort of problem that lots of people are going to notice and report, so you should not dismiss it as Someone Else's Problem™. It really behooves you to accept the responsibility of letting them know. (www.apple.com/feedback
) Include this same snippet from your Console log so they can see what's happening. You won't get any response, but by and by the problem will get fixed.
In the meantime, mds
sees that the file never got indexed, so it tries again. And again. And again...