I realize this topic is a couple years old, but came up on search and figured I would reply instead of creating another one.
I do see the same issue, quite frequently, and have for a long years. I figured it was due to my macbook air being slowish and a little long in the tooth, but I recently got a new maxed out MBP and my total finder install suffers the same issue, despite far fewer things installed and much higher performance/ram. Almost every time I try to access TF after it’s been in the background for a while (hours), or the computer has slept, something freezes up the UI thread and it takes 15-30 seconds for it to unstick itself (which it does most of the time, only very infrequently crashing).
Anyone have thoughts/ideas on how to improve this? It’s not deal-breaking, but it’s really bothersome. Happy to provide any info that may help narrow down causality.
This one will be hard to track down. By the way do you have any crash report which happened in this situation. That could shed some light on this issue.
Please next time this happens again and crashes look for it in Console.app > User Reports > Finder_something.crash
I don’t see any clues there. From TotalFinder’s point of view it looks like a false positive. It wasn’t really TotalFinder’s crash. TotalFinder just happened to be on callstack during that incident so my script treated it as TotalFinder’s fault.
Anyways, the __dirhelper_create_relative and __create_or_fix_relative_directory mention is pretty suspicious.
ok, I’ll keep an eye out. I’ve noticed the same occasional pauses on my current (new) MBP and the iMac that I used before it, so it doesn’t seem to be restricted to one machine, but I work with very similar tooling/apps on both, so it could be some weird interaction. Will follow up if I can come up with any additional info. Thanks for having a look.