Apple Core Rot: Spotlight Cannot Find File Names

2016-01-02 • SEND FEEDBACK |
Related: Apple, Apple Core Rot, Apple macOS

In my photographic work, I often find images by their names (every day), because the name is part of a published article or similar, and I want a quick way to reopen the raw file. To do so, I copy the file name, hit cmd-space to bring up Spotlight, paste the name, and voila: Spotlight finds the file. Well...

The first new bug in Spotlight in OS X 10.11.2 El Crapitan is that pasting the name often pastes only a portion of the name (hit cmd-space, then paste immediately, I get a nearly 100% failure rate on pasting fully/correctly)—yet a new Apple Core Rot bug. For example, pasting “_DSC0131.ARW” may result in only “_DSC0”. So I’ve had to retrain myself to wait just a moment before pasting, a nuisance, but manageable. I’ve noticed additional “delay bugs” like this elsewhere in OS X; the nitwit developers at Apple keep breaking basic functionality, keep making basic things run slow as mud, things that were always lightning fast (save/open dialogs are a good example).

The second bug is much worse: Spotlight simply fails to find the file at all, as shown below. Whether by partial or full name. The volume is not excluded and has been indexed. Here it’s pathetic: a Finder window with a folder showing the file is open right on the screen, even as Spotlight claims the file does not exist. But even when Spotlight finds things, it’s brain-dead. For example, when I enter “name:EmailParser.java”, I want the source code file “EmailParser.java”. Instead I often get a binary file that somewhere inside it has “EmailParser.java”.

How hard can it be to find a file by its complete name anyway? Where Apple OS X was once upon a time “insanely great”, it is now insanely incompetent. When will Apple get its horse apples together?

Spotlight fails to find a file by its entire name

Spotlight doesn’t just miss one file; it doesn’t find *any* of the 11 files with that name. Good 'ol command line (Terminal) finds them all in a second or two:

diglloydMP:Archive lloyd$ find . -name _DSC0131.ARW
./ALLVIEW/SonyA6000/PatriarchGrove-ColorShading/_DSC0131.ARW
./ALLVIEW/SonyA7_II/2014-1226-SonyA7_II-FrostyBackyardMorning/_DSC0131.ARW
./ALLVIEW/SonyA7R_II/2015-0809-SonyA7R_II-StanfordMosaic-sanityChecks/90f2_8/2/_DSC0131.ARW
./ALLVIEW/SonyRX1/2012-1214-SonyRX1-backyard/_DSC0131.ARW
./ALLVIEW/SonyRX100/2012-0809-SonyRX100-MTB-ride-Barcroft-area/_DSC0131.ARW
./ALLVIEW/SonyRX100/SonyRX100-tulips-stitching/tulips1/_DSC0131.ARW
./ALLVIEW/SonyRX100_III/2014-0810-Yosemite-WhiteMountains/_DSC0131.ARW
./ALLVIEW/SonyRX1R_II/2015-1212-SonyRX1R_II-PescaderoCreek/14/_DSC0131.ARW
./ALLVIEW/ZeissTouit/2013-0509-SonyNEX7-Touit12f2_8-MTB-ride/_DSC0131.ARW
./DAP/Coastal60f4/2014-0405-SonyA7R-Coastal60f4-backyard/aseries-Coastal60f4-BlossomClose/_DSC0131.ARW
./DAP/SonyNEX/2012-0129-SonyNEX-5N-color-shading/Leica24f3_8/_DSC0131.ARW

UPDATE: a re-index is in progress; forced using mdutil, by first forcibly erasing the volume, then turning indexing off (just to be sure), then turning indexing on:

mdutil -E /Volumes/Archive
mdutil -i off /Volumes/Archive
mdutil -i on /Volumes/Archive

This ought to fix thing once the indexing is redone (6TB of data takes a long time).

To see status on all volumes, here is the way to look:
mdutil -s /Volumes/*