#Similar to eaglefiler full

Spotlight was the de-facto API for accessing Mail messages. A public API to Core Spotlight should solve that. Where public API to silos exist (PHPhotoLibrary, Contacts, …) the API lack the unifying nature of Spotlight / NSMetadataQuery.In some cases, third-party developers can resort to duplicating effort. This limits integration and automation opportunities. there is no API to access not notes or email messages. Much information is no longer available as siloing proceeds faster than API evolution.The current siloing and move to Core Spotlight has two problems: API to access mail messages is missing.įor example: once access to photos is granted, photos can be accessed via the file system, via scripting, via PHPhotoLibrary, and via MLMediaLibrary frameworks. To me it seems we are actually looking at an incomplete implementation. This allows for application integration, automation, platform extension and avoids duplicated effort. Once consent is given the data should be readily available. The privacy effort is focussed on user consent. I don’t think the siloing of Core Spotlight is part of Apple’s privacy effort or that it actually aligns with this. There’s an obvious conflict between the original Spotlight architecture (every app has access to everything) and the Core Spotlight architecture (every app is siloed), and it’s also obvious that the latter is better aligned with Apple’s ongoing privacy efforts. This reduces the extensibility, scriptability, flexibility and thus usefulness of these core applications and ultimately the platform as a whole. from indexing and thus from access by third party applications. Previous versions of macOS / OS X have removed Safari bookmarks and history, Apple notes, etc. The removal of this OS feature breaks what in essence was public API.Īs a user I am worried to see more and more application data confined to closed “silos”. Mail metadata was readily available and well documented as properties on MDItem. In prior versions of macOS, Spotlight searches allowed programatic access to mail messages. Alternatively one can use Find Email Messages, but this takes minutes before Automator shows a result. We realized, that even Automator has a problem, if one use Spotlight in a workflow. The message files are still there in Catalina, and there’s still a Spotlight importer plug-in that can read them, but you can’t actually search them.Īnd this extends to system apps that use those APIs: Mail has been shifting towards using Core Spotlight for several releases, but until now the actual files in ~/Library/Mail were still searchable. However, though the Spotlight user interface integrates results from both the old file-based Spotlight and Core Spotlight, it seems that the APIs for apps to do their own global querying only work with the former.

This newer API makes it possible to index items that don’t have a one-to-one correspondence with files on disk. This seems to be due to Mail using Core Spotlight. But even if I select “Show in Finder” in the result list, the Finder window is empty. If I search with the default Spotlight interface (command-space), I can find emails. Other content like documents, calendar events and contacts can be retrieved by MDQueryRef. Is this a bug or a feature? Hopefully it’s not a feature. The application logic of our app works for High Sierra bot not for Catalina any more.

#Similar to eaglefiler full

Spotlight search for emails neither works with MDQueryRef nor with mdfind in the Terminal.app even if the user has granted full disc access for the app in the security settings. Spotlight Excludes Mail Folder on macOS 10.15