How Finder can find this file with long name?

Question

Macbook Air 1.3GHz Intel Core i5 8GB Memory DDR3 OSX Yosemite

This is because of the long name, I think:

Hans-Jorg Oestern, Otmar Lorenz Trentz, Lorem Ipsum Lorem Vascular Injuries- Trauma Surgery I (European Manual of Medicine).pdf

I search unsuccessfully

• Hans
• Hans-Jorg
• Hans pdf
• Hans-Jorg pdf

No matches at all. If I make the name shorter, there is a match. It seems that the file is not indexed so the search is not working.

I run the command mdls [filename] and get

kMDItemAuthors                 = (
    "Hans-Jo\U0308rg Oestern, Otmar"
)
kMDItemContentCreationDate     = 2015-02-11 09:37:18 +0000
kMDItemContentModificationDate = 2015-02-18 07:29:29 +0000
kMDItemContentType             = "com.adobe.pdf"
kMDItemContentTypeTree         = (
    "com.adobe.pdf",
    "public.data",
    "public.item",
    "public.composite-content",
    "public.content"
)
kMDItemDateAdded               = 2015-03-23 05:34:10 +0000
kMDItemDescription             = "ISBN-13: 978-3540123123"
kMDItemDisplayName             = "Hans-Jorg Oestern, Otmar Lorenz Trentz, Lorem Ipsum Lorem Vascular Injuries- Trauma Surgery I (European Manual of Medicine).pdf"
kMDItemEncodingApplications    = (
    "Mac OS X 10.10.2 Quartz PDFContext"
)
kMDItemFSContentChangeDate     = 2015-02-18 07:29:29 +0000
kMDItemFSCreationDate          = 2015-02-11 09:37:18 +0000
kMDItemFSCreatorCode           = ""
kMDItemFSFinderFlags           = 0
kMDItemFSHasCustomIcon         = (null)
kMDItemFSInvisible             = 0
kMDItemFSIsExtensionHidden     = 0
kMDItemFSIsStationery          = (null)
kMDItemFSLabel                 = 0
kMDItemFSName                  = "Hans-Jorg Oestern, Otmar Lorenz Trentz, Lorem Ipsum Lorem Vascular Injuries- Trauma Surgery I (European Manual of Medicine).pdf"
kMDItemFSNodeCount             = (null)
kMDItemFSOwnerGroupID          = 20
kMDItemFSOwnerUserID           = 501
kMDItemFSSize                  = 65898547
kMDItemFSTypeCode              = ""
kMDItemKeywords                = (
    "ISBN-10: 3540881212"
)
kMDItemKind                    = "Portable Document Format (PDF)"
kMDItemLogicalSize             = 65898547
kMDItemNumberOfPages           = 435
kMDItemPageHeight              = 747.84
kMDItemPageWidth               = 547.68
kMDItemPhysicalSize            = 65900544
kMDItemSecurityMethod          = "None"
kMDItemTitle                   = "Hans-Jorg Oestern, Otmar Lorenz Trentz, Lorem Ipsum Lorem Vascular Injuries- Trauma Surgery I"
kMDItemVersion                 = "1.3"
kMDItemWhereFroms              = (
    "file:///Users/masi/Downloads/Lorem.pdf",
    ""
)

Time dependency for indexing

I run the same search as above during

• time when asked this question
• 2 weeks after asked this question

and the search did not work.

I run the same search as above about 50 days later and the search works for the file. This proposes me that something is wrong in indexing, since same location of the file.

Some Possible Factors of causing the Bug

• Quartz engine used to construct the file

Other systems where bug reproduced

• some iMac (see grgarside's answer below)

How can you force indexing of such files and make faster search?

Answer 1

I've tried creating a PDF file with that name on two machines and both immediately index the files and provide them in searches for any part of the name. I would be curious to the see the actual content of the file in case the content is somehow causing the indexer to fail, but then you say the indexes okay with shorter names, so it doesn't follow that the content is a problem.

Something you could do is try running mdls against the file. This should show you metadata that is recorded in the Spotlight index for the file. For example when I run it against the PDF I used for testing I get things like the following. You can see here the kMDItemDisplayName and kMDItemFSName are both pulled from the actual name of the file, as the document is just a random PDF about something else entirely that I simply renamed).

kMDItemAuthors                 = (
    se0896
)
kMDItemContentCreationDate     = 2014-12-11 11:38:01 +0000
kMDItemContentModificationDate = 2014-12-11 11:38:01 +0000
kMDItemContentType             = "com.adobe.pdf"
kMDItemContentTypeTree         = (
    "com.adobe.pdf",
    "public.data",
    "public.item",
    "public.composite-content",
    "public.content"
)
kMDItemCreator                 = "Microsoft® Word 2010"
kMDItemDateAdded               = 2015-03-22 22:30:07 +0000
kMDItemDisplayName             = "Hans-Jorg Oestern, Otmar Lorenz Trentz, Lorem Ipsum Lorem Vascular Injuries- Trauma Surgery I (European Manual of Medicine).pdf"
kMDItemEncodingApplications    = (
    "Microsoft\U00ae Word 2010"
)
kMDItemFSContentChangeDate     = 2014-12-11 11:38:01 +0000
kMDItemFSCreationDate          = 2014-12-11 11:38:01 +0000
kMDItemFSCreatorCode           = ""
kMDItemFSFinderFlags           = 0
kMDItemFSHasCustomIcon         = (null)
kMDItemFSInvisible             = 0
kMDItemFSIsExtensionHidden     = 0
kMDItemFSIsStationery          = (null)
kMDItemFSLabel                 = 0
kMDItemFSName                  = "Hans-Jorg Oestern, Otmar Lorenz Trentz, Lorem Ipsum Lorem Vascular Injuries- Trauma Surgery I (European Manual of Medicine).pdf"
kMDItemFSNodeCount             = (null)
kMDItemFSOwnerGroupID          = 20
kMDItemFSOwnerUserID           = 501
kMDItemFSSize                  = 132180
kMDItemFSTypeCode              = ""
kMDItemKind                    = "Portable Document Format (PDF)"
kMDItemLogicalSize             = 132180
kMDItemNumberOfPages           = 5
kMDItemPageHeight              = 841.92
kMDItemPageWidth               = 595.32
kMDItemPhysicalSize            = 135168
kMDItemSecurityMethod          = "None"
kMDItemTitle                   = "Job Title"
kMDItemVersion                 = "1.5"

Another thing you could try is running the manual import tool mdimport with the debug option against both versions of the file (i.e. the file with a long name and again with a short name) and check for differences in the data that is being extracted and imported into Spotlight's metadata stores. The following command (with the correct path to your file of course) should show you which importer is being used and which keys are being extracted. This might help diagnose the fault. This is also a way to force Spotlight to index (or reindex) a file, but I don't think I've ever found that to be necessary. NOTE: The easiest way to perform the following command is to type "mdimport -d 3 " and then drag and drop the file onto the Terminal window.

mdimport -d 3 /Users/USERNAME/Hans-Jorg\ Oestern\,\ Otmar\ Lorenz\ Trentz\,\ Lorem\ Ipsum\ Lorem\ Vascular\ Injuries-\ Trauma\ Surgery\ I\ \(European\ Manual\ of\ Medicine\).pdf"

Answer 2

This has been a bug in Spotlight for a very long time and there does not seem to currently be a workaround except for renaming the file to be a shorter filename, as you have already discovered.

The bug is only present for certain files and folders though and appears more frequently on certain machines. This extenuates the likelihood of it being a bug. For example, I'm unable to reproduce this with the maximum length filename possible in Finder on my MacBook Pro, but Spotlight seems to ignore the same file on my iMac (both with the same version of OS X).

You can provide feedback to Apple here:

• https://www.apple.com/feedback/macosx.html