Replacing Ext4Kit.app in place (any update) leaves ExtensionKit pointing at the previous build's code-signature hash, so the first mount/fsck_fskit/newfs_fskit afterward fails with:
com.apple.extensionKit.errorDomain error 2
NSCocoaErrorDomain 4099 "The connection to service ... was invalidated."
Re-registering the appex fixes it (pluginkit -r/-a, re-enable, kickstart the fskit agent) — that's now in Scripts/refresh-extension.sh and the README troubleshooting. Even after re-registering, I've seen the very first invocation drop the connection once and then succeed on an immediate retry, which looks like extension cold-start.
Two things worth chasing:
- Can we avoid the manual re-register on update entirely — e.g. have the host app re-register its own extension on launch when it notices the on-disk hash changed?
- Is the retry-once-on-cold-start something we can smooth over, or is it just how ExtensionKit spawns the process?
Not blocking — the workaround is one script — but it's a rough first-run experience and it bit me twice while testing 0.1.1.
Replacing
Ext4Kit.appin place (any update) leaves ExtensionKit pointing at the previous build's code-signature hash, so the firstmount/fsck_fskit/newfs_fskitafterward fails with:Re-registering the appex fixes it (
pluginkit -r/-a, re-enable, kickstart the fskit agent) — that's now inScripts/refresh-extension.shand the README troubleshooting. Even after re-registering, I've seen the very first invocation drop the connection once and then succeed on an immediate retry, which looks like extension cold-start.Two things worth chasing:
Not blocking — the workaround is one script — but it's a rough first-run experience and it bit me twice while testing 0.1.1.