Here’s a very quick and unpolished writeup regarding the compatibility of the current public build of TotalFinder 1.14.3 and macOS 13.0.1 22A400 Ventura.
What does not work (public 1.14.3)
[※ SEVERELY IMPACTS USABILITY] Having TotalFinder enabled at all causes some context menu actions to disappear from the Finder right-click menu, regardless of whether or not any TotalFinder context menu tweaks are actually enabled.
The entire Cut and Paste feature, including the Command-X keyboard shortcut as well as the custom context menu buttons.
Copy Path context menu actions do not appear.
Having Coloured Labels enabled at all will cause TotalFinder to completely crash.
※ If you find yourself in such a state, you can manually disable the feature in Terminal using defaults write com.binaryage.totalfinder TotalFinderLabelsEnabled 0
What works (public 1.14.3)
Replacing the Finder Dock icon with the TotalFinder Dock icon
Keeping the original Finder Dock icon (or a custom one set via another tweak)
Showing a progress bar for file operations in the Dock icon
Menu bar item
Colourful sidebar, including Finder icon rendering mode (※ some custom disk icons may not display correctly)
Auto-adjusting column sizes in Column View
Quick-toggling hidden files
Visor
Tabs
Dual View
Compatibility with OpenCore and OpenCore Legacy Patcher
Compatibility with Apple Silicon (※ requires additional -arm64e_preview_abi boot-arg to be set for now)
Compatibility with Intel / AMD (x86_64)
@ChrisOSX@ChrisSpera as well as everyone else patiently waiting for macOS 13 support:
With the current progress in my internal development build, I’m aiming a hopefully-usable beta or something in around a week’s time. Thank you your patience and understanding.
(※ Unlike the previous estimate, this is somewhat based in reality instead of Baseless Guessing™ ;P)
I do NOT recommend disabling authenticated root unless if you absolutely have to for another tweak (※ or are using OpenCore/Clover). Doing so puts you at an elevated risk of making your system unbootable and/or breaking system updates. TotalFinder does NOT require authenticated root to be disabled.
I have a rather interesting problem. Open TF, perfect. Open second tab and I get a document that I examined about a month ago. Close that tab, open a second tab, same document. Uninstall TF, reinstall TF, open it, one tab? Perfect. Open second tab? Same document appears. I don’t even want that second document anymore. ARGHHH!!
For us folks running OpenCore Legacy Patcher, this is not an option. But adding “CSR_ALLOW_TASK_FOR_PID” in the SIP settings is all you recommended before, I still receive the Injection error. Reverting root patches makes TF work again, but I lose other things I need.
I’m on Monterey 12.6.2, with no foreseeable ability to update to Ventura, unless the devs come up with some tricky stuff for us non-metal machines to update.
I’m nothing but patient, and can help where I can, Just let me know.
Keep up the good work!
Huh, what do you mean by “a document appears”? Do you mean Quick Look? What macOS version is this occurring on? My best guess is that this may be some kind of strange Saved Application State behaviour related to Finder…
Ah oops, I clarified the original message a bit to “I do NOT recommend disabling authenticated root unless if you absolutely have to for another tweak (※ or are using OpenCore/Clover).”
It was really only meant for people using supported Apple hardware, since disabling authenticated-root on those platforms leads to a whole bunch of headaches like OS updates no longer working, etc.
But for us in Unsupported Hardware Land™, anything goes ;P
OpenCore, an UEFI bootloader that is capable of booting:
macOS on supported Apple hardware
macOS on unsupported (legacy) Apple hardware
macOS on generic non-Apple hardware
Any other UEFI-compliant operating system, such as Windows (bootmgfw) or Linux (GRUB)
OpenCore Legacy Patcher, a set of rootFS patches that allow a booted macOS system to better work with legacy Apple hardware by injecting necessary kexts and applying other patches/fixes to various parts of the macOS operating system
I can actually personally confirm that TotalFinder works totally fine with:
The OpenCore UEFI bootloader, configured to disable the SIP flags CSR_ALLOW_TASK_FOR_PID and CSR_ALLOW_UNRESTRICTED_FS and booting the following macOS versions:
macOS 13.0.1 22A400 Ventura
macOS 12.6.1 21G217 Monterey
macOS 11.7.1 20G918 Big Sur
macOS 10.15.7 19H2026 Catalina
macOS 10.14.6 18G9323 Mojave
The OpenCore Legacy Patcher root patches for my MacBookPro12,1 to allow proper GPU acceleration on macOS 13.0.1 22A400 Ventura (※ which basically only involves injecting the required kexts for the Intel Broadwell IGP into the rootFS snapshot)
From this behaviour, we can conclude the following:
OpenCore (the bootloader) is not the cause as TotalFinder works fine with it.
Running a system with an unauthenticated rootFS snapshot (required for all OpenCore root patches) is not the cause.
This behaviour is most likely being caused by some patch, kext, or other step that is required specifically for your MacBookPro6,2.
That being said, it just so happens that one of my friends, she actually has an old MacBook Pro that… may be the same as (or at least similar to) yours — in that we know for sure it’s a A1286 but are unsure if it’s a MacBookPro6,2 or simply another similar model, and I won’t be able to tell until I help her get an OS onto it to read the SMBIOS info.
If it is the same machine (or a similar enough one) and I can reproduce the issue, that would be the best outcome and I can try to fix whatever the issue is either on TotalFinder’s side, or help coordinate with the OpenCore team / Dortania to fix the issue upstream.
If not, then I will probably ask you for some debug logs from OpenCore, Lilu, and the OpenCore Legacy Patcher TUI, as I’m determined to get this working for you one way or another. o)-<
For everyone else, here’s a preview screenshot ;P
(※ Screenshot is of my Intel test machine with all features enabled for testing purposes with the exception of Coloured Labels. The erroneously duplicated disk in the sidebar is actually an issue with Finder, and not TotalFinder. The inconsistent behaviour regarding custom disk icons for macOS >= 10.15 is a known issue, and happen due to some technicalities regarding how Apple handles APFS volume groups in Finder.)
Karen, The second tab opens in Quick Look. in my Documents folder. I’ve tried changing the folder, changing the document (always comes back with the same document), deleting TF with the uninstaller in the TF program, deleting TF with my armageddon strength application delete program, rebooting and then reinstalling and there it is again in Quick Look mode. I fixed it by moving that sub-folder it insists on opening every time and now it’s returned to the “Recent” folder list. Not sure what caused it, if I really fixed it or it was just a quirk. None the less it’s opening a standard second tab now. Oh, Version 13.1 Beta (22C5050e).
I can confirm that TF does indeed work, however, you can see in screenshot which root patches OCLP is trying to install. Also, you can see my build SIP settings include all the necessary flags disabled for OCLP and TF.
So, I have some good news — I’ve managed to reproduce your issue on the test machine I mentioned earlier!
It’s actually not quite an exact match for your MacBookPro6,2, as it’s actually a MacBookPro5,1 (the very first in the A1286 series to be released all the way back in late 2008), but they’re definitely similar enough!
The patches we share in common (and therefore making them possible causes) are:
Moraea Framework 【moraea/non-metal-frameworks】 — Most likely the cause, possibly due to some kind of conflict between Moraea’s code injection method and TotalFinder’s.
Legacy Keyboard Backlight 【Moraea_BacklightHack】
Fixes keyboard backlight control on older machines.
Injects into Backlight in SkyLight.framework, injection restricted to WindowServer.
Injects tweak dylibs that are placed in /Library/Application Support/SkyLightPlugins into all processes that load SkyLight.framework (including WindowServer).
I haven’t taken much more than a cursory glance at all this though — specifically, I haven’t looked too deeply into what the OpenCore team is doing with their fancy Moraea code injection framework, but I will definitely try and get this resolved one way or another, either from TotalFinder’s side or from Moraea’s.
※ EDIT: Oh, huh. I just noticed, it seems that applying the OpenCore root patches (at least for the MacBookPro5,1) actually also breaks macOS’s built-in sshd… somehow.
This is an strange one for me. There was a point where my machine needed the backlight hack. But something in one of the updates made it work sporadically . I noticed a few times ago before I applied root patches.
I have responded to the DM with the necessary info. It does indeed break it…odd.
TotalFinder 1.14.4 beta development progress report
While the beta is indeed technically usable in its current state (in that there are no known crashes, and is a net improvement over 1.14.3), I don’t know how I feel about releasing something that is pretty much half-baked with missing features, as my standards for releasing beta software is usually “this should mostly work as intended, but there may be unforeseen bugs, or a few known issues that are either very minor or otherwise do not significantly impact functionality”.
In any case, here’s the progress report for those who may be interested:
What’s been fixed so far
Native Apple right-click context menu actions are no longer missing.
Copy Path context menu actions are fully working.
Having coloured labels enabled no longer causes Finder to crash.
Cut and paste partially works. (※ See below for further details.)
Coloured label rendering in all views (list, icon, desktop icon, and column) fully works, but… (※ See below for further details.)
What still needs to be addressed
Cutting a file/folder and attempting to paste it (either via Cmd-V or the context menu) into the current directory does not work.
Pasting it into a selected/highlighted folder via right-click works, however.
An unintended bug also currently exists that allows you to do this via Cmd-V as well, but this will need to be removed/fixed as it subverts user expectations and is not how the feature should behave.
Pretty much everything to do with coloured labels has been fixed… except one crucial piece of functionality: The ability for TotalFinder to look up the assigned tag colour of a given file/folder.
Apple made quite a few under-the-hood changes to Finder in macOS 13, one of which has made this… unexpectedly difficult, let’s say.
(It also doesn’t help that Finder is one of the more… convoluted apps that I’ve seen come out of Apple, which just makes reverse engineering it that much harder ;P)
Hopefully… I can get this figured out soon. While there’s pretty much “just” two things left to deal with, both of those things ended up being… more complicated than expected.
Once again, my apologies for the delay!
※ Also, regarding the code injection issues that occur on certain specific non-Metal Macs using OpenCore Legacy Patcher: I’ve gotten into contact with some people (including Amy/ASentientBot) on the OCLP team. This is most likely something that will have to be fixed from the OCLP side of things though, as their root patches on these particular machines are actually causing other broken behaviour, too.
You shouldn’t have to apologise, you can’t foresee how much time is needed for fixing something that’s changed so far than expected… moreover, I think I can speak for everybody here, we are grateful to you for every hour you spend for TF and also for the really detailed reports you are sharing with us.
Most likely the cause, possibly due to some kind of conflict between Moraea’s code injection method and TotalFinder’s.
Most likely not the cause.
