After updating to 10.14.4. GitFinder stops working

[jc4711]

After updating to 10.14.4. I am seeing 'Sending message from Finder extension to application failed' dialog. Only option is to quit. Please fix.

[milke]

In order for GitFinder application and Finder Sync extension combo to work properly, the extension has to be started by the application. Unfortunately, the OS also can start the extensions before the application is started and then the application - extension combo goes out of sync. I tried my best to prevent such situations, but they still happen sometimes, like in your example when updating the OS.

The solution is pretty simple. Once you quit the application, open Activity Monitor application and find process(es, there may be more) named GitFinderSync, just like on the picture below:

Select those processes one by one, click the far left button to kill the process, and in the sheet that appears choose Force Quit. Then launch GitFinder application again and everything should go back to normal.

Let me know if this helps. I’ll try to make some changes in the application to handle similar situations more graciously in the future.

[Lepozuk]

in macos 10.14.5 still got same problem:

[milke]

@Lepozuk, it's not related to OS update, I explained to @jc4711 above why this happens and how to "fix" it. So please, do like advised above.

On a related note, I'm preparing (quite huge feature-wise) update 1.3 and it will also handle this kind of situations more graciously.

[milke]

@kcorey, as I've mentioned in #54, I'm continuing it here…

Finder Sync extensions are really tough beasts :-( I say this not to excuse myself, but they really are and you'll see why. I'll be a bit more elaborative, but I hope you'll find it helpful and informative.

At the very least, the GitFinderSync process should have its own icon in the title bar allowing for easy quitting.

Actually, developers are advised to limit Finder Sync extensions functionality only to "handling the badges, contextual menus, and toolbar buttons" and they are supposed to run like menu-less (LSUIElement) applications, which don't present themselves in the Dock, nor the main menu. And believe me, I have that enabled during development (just to make my life easier) and it really looks ugly, weird and impractical to have both application and extension presenting their UIs.

The next best would be to realise when GitFinder itself has died, and then GitFinderSync should die.

Yeah, that's a logical thing, if the application is not running, its Finder Sync extension (from here I'll refer to it only as extension) should not run as well. Unfortunately, launching and termination of extension is controller by the OS, it should NOT be controlled by the containing application, in which the extension is bundled (from now one, I'll refer to it only as application). Moreover, the documentation says "the system may also launch additional copies of your extension whenever an Open or Save dialog is displayed. This means that the user may have multiple copies of your extension running at once, and some may be very short lived" and it's OS's responsibility to handle their life span. However, I realised it's illogical to have one running without the other, so after a lot of experimenting and trying, combined with input from some users, I came up with the following workflow… This is actually how it all worked until up to version 1.3.1 and it worked really fine for a while.

• on launch, the extension would check if the application is also running. If not, it would just terminate itself.
• on launch, the application would make sure to start its extension. Now, this is not straightforward (unless you restore to command line tool, but I couldn't use that as GitFinder is fully sandboxed), but there's an undocumented private API call to actually "register" the extension. A handle to the extension itself is also acquired using another private API call. By executing that all, hence registering the extension, the application could be sure the extension would be started and everything worked fine afterwards.
• on termination, the application would make sure to send messages to all running extensions to terminate as well, so on application termination everything related gets terminated as well.

This all worked really well, up until version 1.3.1. In the rare situations of lingering alive extension (most probably after eventual crash of the application) the message shown above (which you see as well) would sometimes appear and the above workaround of quitting the application and forcibly killing extensions was enough to get you going again.

Things changed with Catalina, as Apple apparently changed something in the way extensions are handled. That proved that (as per documentation) I wasn't supposed to mess with extensions life span, like I did. In Catalina, once the application terminated and send messages to extension to terminate as well, after extensions were terminated, there was no guarantee you could start them again when launching the application. The mentioned private API call to register the extension wasn't enough, it wouldn't work. In order to make it work, I had to use another private API call to first "unregister" the extension and then immediately register it again.

To fix this issue, I changed things in version 1.3.2 so if running on Catalina, on termination the application would send all running extension to terminate as well (like before), but it would then also unregister the extension, so that everything is clean and ready for registering the extension on next launch of the application. Also, on launch would application again check if the extension is perhaps registered (because user could go into System Preferences > Extensions > Finder Extensions and register it manually there by checking GitFinder checkbox) and if it is, it would in succession first unregister and then immediately register it back, so everything works fine.

A lot of work, right? Unfortunately, this workflow brought some negative side effects. They were minor, but still annoying to users. For example, if you put GitFinder toolbar item in Finder, so that you can invoke GitFinder actions from the toolbar and not only the contextual menu (see the picture below), unregistered the extension would remove that toolbar item and as a consequence, it would be lost every time the application is launched and user would have to put it there again. Just to lose it again on next launch :-(

Hence I finally ended up with the solution in version 1.3.3 and it's still present in the current official version (**1.4.1). The application DOES NOT try to control the life span of extensions, like Apple suggests, that work is left to the OS. And I really don't want to change that, since it bit me once and it would probably bite me again. I only did my best to make sure everything regarding communication between the application and its running extension(s) is in order.

Unfortunately, that error message may still appear in some rare cases. The above mentioned workaround is still valid on pre-Catalina systems. However, I just did some extensive testing on Catalina (if you believe, it's still NOT my primary macOS version), and the workaround may work sometimes, but in most cases it does NOT :-( There is one additional step, so the while procedure should be like this:

• when the error regarding miscommunication between the application and the extension appears, click OK, that will terminate the application.

• open Activity Monitor application and find process(es, there may be more) named GitFinderSync. Select those processes one by one, click the far left button to kill the process, and in the sheet that appears choose Force Quit.

• Go to System Preferences > Extensions > Finder Extensions and uncheck GitFinder checkbox (see the picture below). That would unregister the extension.

  

• Launch GitFinder application again and everything should go back to normal.

Of course, this is not the ideal solution, and while doing all those tests again, I've got some ideas how it all could be (hopefully) done programatically for you, so you as a user would not have the mess with all details, just clicking that OK button and relaunching the application should be enough to get you going. I will release version 1.4.2 in about two days, as some users are waiting for some fixes in there, but I'll start working on 1.4.3, which should contain the fix for the above case. I'll first release it as a beta and let you know, so you can give it a spin and see if it works fine. If everything is okay, I'll release it as an official version.

[milke]

Version 1.5 brings some more robustness in handling this issue. Hopefully it won't happen again, but if it does, feel free to reopen this issue.