Hello,
I'm working on a project for a file system using FSKit and I'm currently experiencing a strange issue on macOS 26 to which I updated recently. While testing, I'm doing incremental debug builds using Xcode. I'm very careful to make sure I only have a single instance of the built app (hosting the file system extension) anywhere on disk. I run the app, mount the file system, run some tests, unmount, kill the app, make changes, and repeat. Once in a while, however, mount would suddenly start failing with
mount: Loading resource: The operation couldn’t be completed. (com.apple.extensionKit.errorDomain error 2.)
mount: File system named MyFS not found
This would consistently repeat until I clean the build folder, rebuild and run again. I would continue testing for a while, then at some point mount would start failing again.
I looked at the system logs and found this message from extensionkitservice:
Failed to initialize _EXExtensionIdentity: Error Domain=com.apple.extensionKit.errorDomain Code=5 "Failed to find extension: 24B7F729-5AD1-4486-92B4-1F57CACCA265"
So I started going through the logs in more detail and found the following:
lsd seems to unregister and register the file system extension occasionally, each time giving it a different UUID. I can see logs about "com.apple.LaunchServices.pluginsregistered" and "com.apple.LaunchServices.pluginsunregistered" notifications being sent with their data. What seems to be the problem is that sometimes after this happens, when I attempt to mount the file system, the extensionkitservice would fail to find the extension because it is referencing it using one of its previous UUIDs assigned by lsd, not its latest one, judging by the UUID in the log message.
Am I doing something wrong here? I think I may be causing the constant unregister/register of the extension idirectly by rebuilding via Xcode. Or is it a problem with extensionkitservice? I've never had this happen on Sequoia.
macOS 26.0.1 (25A362); Xcode 26.0.1 (17A400)
Thank you
Am I doing something wrong here?
No, not really. I've actually seen variations of this failure across all macOS versions going back... well, basically "forever". The details of EXACTLY how it plays out vary across system versions, but the basic dynamics at work here are:
-
LaunchServices "works" by detecting when apps/components "appear" in the system, then reading the data from those components into its database.
-
The nature of the development process means that you can easily produce "new" apps with a speed and volume WILDLY higher than any normal user would.
-
The entire system is regularly interacting with the LaunchServices database at exactly the same time you're changing that configuration.
...the net result of which is that "something" occasionally goes wrong, leaving bad data in the database.
I think I may be causing the constant unregister/register of the extension directly by rebuilding via Xcode. Or is it a problem with extensionkitservice?
It's certainly "a bug" and, if you haven't already, please do file a bug on this and post the bug number back here. These failures are considered serious and we do fix them. However, a few points I'd note here:
-
While I've seen these issues happen to many developers, they're much, MUCH rarer on end-user systems. The unique dynamics of the development process are the single biggest factor here.
-
The fact this "keeps happening" is a side effect of LaunchServices’ basic role, NOT a lack of attention or maintenance. That nature of LaunchServices’ role in the system means that it really only "fails" in one way ("something wasn't found, didn't launch, etc..."), which means lots of unrelated failures end up looking exactly the same.
Finally, just so this is clear, it's unlikely that there is any "deeper" failure or larger "harm" going on here. LaunchServices is simply failing to register a new build properly, which leaves it stuck with stale data. Doing this:
This would consistently repeat until I clean the build folder, rebuild, and run again. I would continue testing for a while, then at some point, mount would start failing again.
...is simply forcing a new registration cycle through the database, clearing the issue.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware.
