[INFO] BetterZip Finder Extension conflict with GitFinderSync

[AddictArts]

Just wanted to pass along that BetterZip is always causing a conflict with GitFinderSync. If I turn it off viola GitFinderSync starts working and Finder icons appear. Turning off is unchecking in the System Preferences -> Finder Extensions. I can turn on again, however if the app updates, either, I have to repeat the process.

[milke]

It's not about those two particular extensions, it's about FinderSync extensions in general. If two (or more) FinderSync extensions monitor the same folder(s), they collide over which one would present its own icon badges. And that happens even if some extension doesn't even provide any badges (like BetterZip in this case). The extension which wins over is the one started first after login. But FinderSync extensions are started by the OS and that process is, as far as I know, uncontrolled and the order of extension started is unpredicted.

The trick here is to go over all FinderSync extensions in System Preferences and uncheck all, but the one you want to show its icon badges (GitFinder in this case). Once the desired extension takes over badge presentation, you can check back the others. So, all FinderSync extensions can function at the same time and present their contextual menu items/commands, but only one can present icon badges, which is logical. What is not logical is that Apple hasn't provided a way to prioritize which extension will show its icon badges. I filed a bug report long time ago (at the time macOS 10.11 El Capitan was still the latest version), and nothing happened in the meanwhile.

You can read all this (and some additional explanations) in #120 , where the same issue was reported.

Also, this is all explained on the support page, section FAQ, question GitFinder is running, but I don't see icon badges nor git menu commands? (second half of the answer). Pictures provided there refer to previous System Preferences (pre-Ventura), but the story is essentially the same. Use this "trick" if you encounter this issue again. And maybe one fine, bright day in the future, Apple will provide some better solution 🙂

[AddictArts]

@milke thanks. However, 100% of the time I have no conflict with OneDrive or Dropbox for example. If I leave BetterZip enabled and eventual reboot, OS update, etc GitFinder will be the looser and BetterZip wins. Forcing me to go to extensions and un-select BetterZip and GitFinder, re-select GitFinder.

So, technically it can be anything, but to the user it appears to be a conflict between BetterZip and GitFinder. A very specific conflict, not the general kind like other extensions.

BetterZip has no badges unlike Dropbox for example. So, why the conflict? It just adds context menu. Something else is going on and the info here can help someone else who wonders why GitFinder quit working.

[milke]

@AddictArts, I apologize for delayed response. I was on a holiday and then I forgot to respond and provide some more information. I hope it isn't too late and the information provided may be useful to others stumbling upon the same problem. Also, this response is a bit more technical, hoping it will provide better explanation of what's going on.

BetterZip has no badges unlike Dropbox for example. So, why the conflict? It just adds context menu. Something else is going on and the info here can help someone else who wonders why GitFinder quit working.

There's nothing else going on, but what I've already explained. There is a collision between GitFinder and BetterZip about who will display its icon badges and for some reason BetterZip wins. The fact that BetterZip has no badges makes no difference (more about that below).

However, 100% of the time I have no conflict with OneDrive or Dropbox for example.

Most likely because OneDrive and Dropbox don't monitor same folders as GitFinder (more about that later).

Here comes the detailed (to the best of my abilities and my English language skills) explanation…

Every FinderSync extension's entry point is a subclass of FIFinderSync, complying to the protocol with the same name FIFinderSync. Upon initialization, this singleton object should specify which folders (within all available file systems) the extension will monitor. This is done by sending -[FIFinderSyncController setDirectoryURLs:] message to [-[FIFinderSyncController defaultController]](https://developer.apple.com/documentation/findersync/fifindersynccontroller/default()?language=objc). The extension will provide icon badges and contextual / toolbar_item menu items ONLY for files and folders which are descendants (down to all available children) of folders specified when sending -[FIFinderSyncController setDirectoryURLs:] message. If two (or more) extensions specify the same folder when sending this message, then they both (or more) will monitor the same folder. That means two (or more) extensions will provide icon badges and contextual / toolbar_item menu items for that folder and all its descendants (down to all available children). When two (or more) extensions try to provide contextual / toolbar_item menu items for a file, that's not a problem, all menu items from all monitoring extensions will be there. But when two (or more) extensions try to provide icon badge for a file, that's a problem, since only one icon badge can be displayed. The first extension sending -[FIFinderSyncController setDirectoryURLs:] message (specifying folders to monitor) will win in this collision and it will display its icon badges (for clarity I'll call it the winner extension further on). Other extension(s) monitoring the same files won't be able to do so (for clarity I'll call it the loser extension(s) further on). -[FIFinderSyncController setDirectoryURLs:] message is advised to be called in the initialization of the extension's FIFinderSync subclass, which means that the extension started the earliest during user login is the winner extension and it will display its icon badges.

The winner extension will regularly receive -[FIFinderSync requestBadgeIdentifierForURL:] message, meaning the OS gives the winner extension the opportunity to provide icon badges to the OS (for displaying in Finder) by sending -[FIFinderSyncController setBadgeIdentifier:forURL:] message to -[FIFinderSyncController defaultController]. The loser extension will NOT receive -[FIFinderSync requestBadgeIdentifierForURL:]` message from the OS, hence it has NO opportunity to provide icon badges to the OS.

The order extensions are started is determined by the OS. It seems BetterZip's extension is always started before GitFinder's extension and I don't know why that happens. Hence, BetterZip almost always win over GitFinder.

However, 100% of the time I have no conflict with OneDrive or Dropbox for example.

Knowing the above, you don't see the collision with OneDrive or Dropbox, because they don't seem to monitor the same folders as GitFinder does. As far as I know, OneDrive monitors its default folder (usually ~/OneDrive unless specified otherwise in settings) and possibly ~/Documents. Also as far as I know, Dropbox monitors its default folder (usually ~/Dropbox unless specified otherwise in settings) AND ~/Documents (I have no idea why they decided to monitor ~/Documents, since Dropbox doesn't provide icon badges or menu items for it). If GitFinder doesn't monitor those folders, there won't be any collisions.

BetterZip has no badges unlike Dropbox for example. So, why the conflict?

Like I've already mentioned, it doesn't matter if an extension displays icon badges. Once the extension wins the collision (being started the first by the OS), it gets -[FIFinderSync requestBadgeIdentifierForURL:] message to display a badge for a file and it may choose NOT to display any badge by NOT calling -[FIFinderSyncController setBadgeIdentifier:forURL:]. The loser extensions will NOT get -[FIFinderSync requestBadgeIdentifierForURL:] message at all, hence they have NO chance to offer their icon badges to the OS at all! Even trying to force displaying badges from those extensions by calling -[FIFinderSyncController setBadgeIdentifier:forURL:] from arbitrary parts of the code does NOTHING. There's simply no way for the loser extension to provide its icon badges to the OS, even if the winner extension chooses NOT to offer its own icon badges. It seems BetterZip extension monitors complete home folder ~ and possibly some other folders (perhaps /Application, some folders in /System and /Library as well as roots of all mounted remote and/or network volumes), essentially preventing GitFinder extension from displaying its icon badges for EVERY file.

I hope it's now clear what happens and why GitFinder can't show its icon badges if BetterZip wins the collision, even if BetterZip doesn't provide icon badges at all.

What can be done about this? I will try to investigate if I can influence the order the OS starts extensions during user login. I'll try to find if there's something in extension's implementation that can increase extension's starting priority. I plan to do so by developing another test extension and running it together with GitFinder and see if there's any way I can influence their order of startup/initialization. If I manage to do something about it, there will be an update of GitFinder with the solution.

I'm open for further questions, comments and clarifications on this whole subject.

[AddictArts]

@milke Thanks for looking into it. I mostly just wanted to capture information about the weird interaction of BetterZip. It is the only extension that does this for me at least. Dropbox and OneDrive behave as expected. Maybe this could help someone else.

I am no longer using Mac much and my Mac OS is way out of date now. So, I am going to close it.