Thanks for the suggestion, but it also didn’t help in my case.
Besides the plists from the preferences folder I deleted:
./Application Support/.TotalFinder.lock
./Application Support/.TotalFinderAgent.lock
~/Library/Application Support/Total Finder didn’t exist in the first place!
Yes, I would wonder if @plmtr’s steps would solve the issue.
TotalFinder does not create ~/Library/Application Support/Total Finder and com.binaryage.totalfinder.plist is created by Sparkle library.
Is this no longer a problem?
I’m still not using my beloved TotalFinder. It crashed Finder every time. I looked for the remnant files that were mentioned, but they weren’t on my Mac.
I was unable to reproduce it on my machines and for some reason suddenly people stopped sending new complaints. Also I focused on Yosemite compatibility last week which has priority right now.
I’m sorry. If anyone could try test older releases and pin-point the version which broke, that would be helpful.
Good news. I was able to reproduce initial CPU hog on my machine.
The problem was caused by my TotalFinder starting in dual mode and having “All my files” in the right pane. Under some circumstances Finder is updating icons (and metadata) of this long list of files several times a second and this causes TotalFinder to re-apply sidebar mirroring hack multiple times. This alone would not be a problem, but this rapid queue of update requests caused an infinite loop of TotalFinder updates - in other words: my code touched some Finder views and this scheduled another update, which in turn touched some Finder views, scheduling another update => ending up in infinite loop of updates.
I’m working on a fix. This weekend I should have a new beta release out. Hope this nasty issue will be a history.
TotalFinder 1.6.1 should not exhibit this problem anymore:
http://totalfinder.binaryage.com/beta-changes#1.6.1
Thanks for confirmation.
I wish I could say this worked for me, but I installed 1.6.1 and I still get “Application not Responding” on Finder as soon as it launches.
Update didn’t solve the problem for me neither!
I have found a workaround that really works. I’m using 1.6.1, and the most important thing, if you’re working in a network environment, is to NOT have TotalFinder in your Login Items. Use regular Finder, log in to all network drives you use, and THEN click a TotalFinder icon that you’ve put on your task bar, and it starts right up, ready to go, no spinning beach ball. An awesome improvement to productivity if you identify file categories with colorful labels rather than Mavericks’ tags.
Note that every time you install a new version of TotalFinder, it sets itself to start every time you start your computer by putting itself in your Login Items. Simply delete it from Login Items right after you install it.
Hello everyone,
So far I have been unable to reproduce this pesky issue on my machines.
I decided to announce a bounty for whoever provides me with information leading to resolving this bug. Please submit your findings to support@binaryage.com. I would be glad to get some reproducible steps if possible. Or someone to test which beta version first started to express this behaviour.
For some reason come Macs freeze Finder with version 1.6.1 and some do not. I just uninstalled and reinstalled version 1.6.1 of TotalFinder from a 2009 Mac Mini and a 2010 MacBook Pro. On the former everything works normally, on the latter the Finder process eats up all available CPU. I have no other clue than the graphics adapter (and driver) not being the same. Both Macs are running OS X 10.9.4. And I tried running the MacBook Pro using only discrete graphics card, but Finder still crashes, so the issue is not related to graphics card currently in use.
Right after starting TotalFinder on a computer having the Finder using 100% CPU issue, the Console application starts filling up with the following error message:
02/07/14 19:01:32,223 Finder[1282]: FIXME: IOUnserialize has detected a string that is not valid UTF-8, “}W��”.
There are maybe half a dozen of exact same error messages per second, and it goes on and on and on until I kill Finder.
Thanks, this is interesting. That is definitely not message logged by TotalFinder’s code.
Googling and I can see there are many mentions on the interwebs.
Could you please do some tests on your affected machine?
If the issue is 100% reproducible and caused by TotalFinder’s code, we could try to disable individual TotalFinder pieces one by one to isolate binary causing the trouble. It could be that TotalFinder corrupts some regions of Finder memory and that is causing the problems.
Please try these commands in Terminal.app, Finder restart is needed after each of them, use no to disable their effect again:
First try to disable all plugins:
defaults write com.apple.finder TotalFinderAllPluginsDisabled -bool yes
Then try to disable them one by one:
defaults write com.apple.finder TotalFinder[PLUGIN]Disabled -bool yes
Replace [PLUGIN] with these one by one:
Tabs
ColorfulSidebar
ColumnViewAutoWidth
CopyPathMenu
CutAndPaste
DockProgressBar
FoldersOnTop
Labels
NoDesktopDots
SystemFiles
Visor
I’m on the road, but I have working VPN connection to the affected computer. I’ll let you know asap.
It seems to crash even after disabling all plugins, so I was stuck at step 1. It opens a “Check for updates automatically?” dialog, but at that point the software is not responding anymore.
I have the similar (same?) issue where TotalFinder keeps crashing the Finder. Interestingly, another user account on the same macbook pro works fine. I tried deleting all login items on my current account, but still, TotalFinder does not work. So it must be more low-level than that.
I tried what you suggested, and TotalFinder runs when “Tabs” is disabled. But in this case, TotalFinder is worthless as I cannot use the visor function.
Disabling only the “visor” does not work, however.
Hope this helps.
SJK
Now I tried this once more after rebooting the computer. Disabling all plugins keeps Finder working. Then I enabled everything and disabled just the Tabs and it still works after Finder restart. Enabling Tabs and restarting Finder and TotalFinder, Finder starts the CPU 100% loop again. So for me it’s the Tabs that is causing the problem.