Thank you very much for your technical support. I will reinstall the Mac Book system to try to use TF
Interesting.
Since folders can now be named with emojis, how do other file systems (e.g., exFAT, ext4) or cloud backup systems like Backblaze “read” emojis as filenames when they’re copied to them from APFS?
If I have a folder, ~/Desktop/ 
, and I copy it to my NAS and then I connect to the NAS from a Windows or Linux machine, how is that folder displayed? Do Linux and Windows also support emoji in file/folder names?
Also, if I drag a folder with an emoji name into the Terminal, the path ends with the emoji image. But I assume the system must be translating it into a text name or something.
It would be fun to use emojis to name folders and files, but I would be afraid of data loss if I ever had to restore these emoji-named folders and files from a backup, especially from a NAS or cloud backup.
1 Like
@strafer This may seem very counterintuitive, but emoji are actually text.
Well, that’s an oversimplification. What I mean is that they’re Unicode codepoints. Which is basically text.
Basically, what this means is that emoji are actually encoded and handled in the same way that say, a Japanese character would be.
For instance:
あいうえお (a i u e o, the 5 vowels written in Japanese hiragana script)
- In UTF-8 representation, the above would be
\xe3\x81\x82\xe3\x81\x84\xe3\x81\x86\xe3\x81\x88\xe3\x81\x8a. - In UTF-16 representation, the above would be
\u3042\u3044\u3046\u3048\u304a.
aiueo (same thing as above, but now with Latin characters)
- In UTF-8 representation, the above would be
\x61\x69\x75\x65\x6f. - In UTF-16 representation, the above would be
\u0061\u0069\u0075\u0065\u006f.
🍍🌺🎋🍕🌭
- In UTF-8 representation, the above would be
\xf0\x9f\x8d\x8d\xf0\x9f\x8c\xba\xf0\x9f\x8e\x8b\xf0\x9f\x8d\x95\xf0\x9f\x8c\xad. - In UTF-16 representation, the above would be
\ud83c\udf4d\ud83c\udf3a\ud83c\udf8b\ud83c\udf55\ud83c\udf2d.
Basically every modern (or modern-ish) filesystem in use today — APFS, HFSJ+, ext4/ext3/ext2, ZFS, NTFS, exFAT, and even FAT32/FAT16/FAT12 (thanks to Microsoft’s backwards-compatible “Long Filename” feature) supports storing and retrieving unicode characters as filenames or directory names.
Generally speaking, the only issues you’d potentially run into are if you tried to view these filenames using an operating system that doesn’t correctly supports Unicode, such as early versions of Windows XP.
But even then, you’d still be able to access the files. The folder name would simply be displayed incorrectly, as mojibake. (tl;dr: A Japanese word that ended up in the English lexicon, used to describe what happens when a non-Unicode aware OS attempts to render Unicode text with the wrong encoding.)
When dealing with actual data access or I/O in filesystems, computers really only care about the raw UTF-8/UTF-16 representations I showed above. Actually displaying said Unicode data to the end user is a completely separate thing. As a result, data loss due to Unicode filenames doesn’t happen. (If it did, a large portion of the world would be screwed…)
As for how your emoji will render/display on each OS… that’s just up to each individual OS’s emoji support. If your OS doesn’t support rendering a specific emoji, you may see a � replace it instead.
Hopefully this makes sense to you.
tl;dr: Emoji are text. Naming something with emoji is just like naming it in Japanese or another foreign language script. As for how it’ll be displayed, it’ll probably be correct as long as you’re using a reasonably modern OS. Really just depends on the emoji support in general on said OS. Data loss shouldn’t really happen — all modern filesystems support Unicode. Also, the rest of the non-English-speaking world use computers too ;P
※ Fun fact: There are actually literal Egyptian hieroglyphs in Unicode, as well.
1 Like
Yes, thank you, that makes sense. Very helpful.
1 Like
I’m running TotalFinder under Monterey Beta 21F5071b (12.4 beta 4) on a M1 MacBook Pro Max and it’s running very well. It’s great to have it back and operating like normal. I tried PathFinder and a bunch of other programs but none did everything (or as well) as TotalFinder. Thanks for your great work.
1 Like
Hello, first off many thanks for the update. I wasn’t looking forward to a future of Apple Silicon minus TF. I just wanted to add my two cents as to what I’m observing with native tabs on two Mac platforms:
-
2020 iMac (Intel, Big Sur 11.6.5) TF has native tabs on both sides in dual mode, but the native tabs on the right won’t go the full width of the frame. This issue has been present at least since Big Sur’s release.
-
2021 Mac Mini (M1, Monterey 12.3.1) TF installs and runs fine, but native tabs in dual mode don’t work at all on the right side. Trying to get them to work makes both sides inoperable.
Again, my eternal gratitude for the update!!
2 Likes
Thanks for much for this! I’ve completely avoided upgrading past 10.15 or buying new Macs, and this was one of the biggest reasons (the IU and lack of control in 11+ is awful). I’ll be testing this on my family M1 Mac mini. Maybe this will finally convince me to upgrade my 2010 Mac Pro to an Apple Silicon Mac.
1 Like
Hi! akemi_dayo. Thank you so much for your updates and detailed information (most of which I don’t understand, but it looks like pretty much everyone else does!!!). I have just had to switch to an M1 Mac and am completely traumatized by the bland SideBar. When do you think your update will come with the working Colorful Sidebar?
As a side note: I am so amazed that Apple doesn’t consider this to be an accessibility issue. I am an older user and find it so hard to visually differentiate between the folders that all look the same as my brain just doesn’t process as quickly as it did several decades ago.
1 Like
Unfortunately, it appears that Total Finder 1.14.1 does not work on MacOS Ventura 13.0 beta. I’ve tried everything suggested and nothing seems to make it work. I’ll be happy to send you any information you require to make TF work, just let me know what you need.
1 Like
Hello @akemin_dayo , 
i have also macOS 11.6 (11.6.3) on Apple Silicon M1 and TotalFinder won’t work.
I have taken all the steps you mentioned here, but where can I see that it is usable?
The Activity Monitor shows a process, but nothing else is happening.
Kindest regards. Jack
1 Like
@JB76 Reproduced and confirmed. TotalFinder’s handling of native Finder tabs is indeed… somewhat buggy on those versions (possibly 10.15 Catalina too, I haven’t gotten around to that version yet as of this writing).
Curious though, is there a reason why you’re using native Finder tabs in addition to TotalFinder tabs?
@Sames I’m aiming to hopefully release 1.14.2 within the next few days. Just putting finishing touches on some things.
I think it’s worth filing a Radar / Feedback report to Apple regarding this.
I know feedback reports to large companies very often feels like shouting into the cold, uncaring void, but I do think that if enough reports of this as an accessibility concern show up in their system, perhaps something will be done about it (or at least they will be aware of it), since I think many at Apple (and even outside of it) haven’t thought about this from an accessiblity angle before.
@Ken I plan on properly testing TotalFinder on macOS 13 Ventura soon — Apple kind of made things a bit complicated for me with this update with regards to testing on Intel since they actually… dropped support for the Intel machine (a 2015 MacBook Pro…!?) that I normally use to test macOS developer seeds.
(At least I’ll be able to test with canned-mac for Apple Silicon while I figure out the situation with Intel.)
@JackCico Try running csrutil status at the Terminal — what does it output?
Also, I am curious — is there a particular reason why you’re staying on macOS 11 Big Sur? You’re the third person (or something like that) I’ve seen in this thread doing this, and at this point I’m genuinely curious if there’s some common reason you all have for doing this.
Of course, I still do want to fix whatever strange issue it is you all seem to have experienced (an issue that I, for some reason, am still unable to reproduce on any of my Big Sur testing environments, both Intel and Apple Silicon……………)
@akemin_dayo I have noticed that with TotalFinder working now, the Asepsis descendent Odourless, which attempts to suppress .DS_STORE creation, is not compatible.
This may well be something for the Odourless developer to work out, and I’ll create an issue on Github about this too, but I thought I’d raise it with you too 
I’d love to have both tools working together!
1 Like
TotalFinder 1.14.2 has been released to the beta update channel!
It will be moved to the stable update channel in a few days, if everything goes smoothly for everyone.
If you would like to get TotalFinder 1.14.2 now, you can either:
- Enable checking for pre-release versions in the TotalFinder preferences, or…
- Download and install the TotalFinder 1.14.2 DMG directly.
This update addresses issues and new feature requests submitted by: @strafer @shh_sg @Leo_B @Davi @Sames
The first post in this thread has been updated accordingly with the changelog for 1.14.2.
5 Likes
@Peter_Hollo I just tested this — the issue actually has nothing to do with TotalFinder (as I get the injection error even with TotalFinder disabled and/or fully removed), but rather the fact that Odourless in its current state doesn’t actually work correctly on Apple Silicon.
Basically, Finder (and all other Apple platform binaries) are arm64e, but all of Odourless’s arm64e executable binaries (except maybe the dylib) are broken and get SIGKILL’d instantly, resulting in them failing to launch at all.
Now, if you were to download the arm64 version of Odourless instead, this on the other hand does launch, but it fails to inject into Finder due to an architecture mismatch between Finder (arm64e) and libodourless-inject.dylib (arm64), hence the “Incompatible Mach-O image” message.
Simply transplanting the arm64e dylib into the arm64 app bundle also does not work.
In any case, I’ll make a comment on the GitHub issue and continue the discussion there.
Thanks for bringing this to my attention!
Thanks so much @akemin_dayo! You’re a legend, as usual - thanks for your in-depth analysis.
And apologies. I did think that Odourless had worked for ARM architecture, but perhaps it never did.
FWIW the daemon log was not giving the “Incompatible Mach-O image” error unless TotalFinder was running. And yeah, the arm64e build wasn’t even launchable.
My Parallels-using self would be super happy if it could be working on Apple Silicon! And nice because Asepsis was in fact originally part of TotalFinder before @darwin separated it out
3 Likes
@Peter_Hollo Yeah, I was also an Asepsis user up until it stopped being supported in OS X 10.11 ;P
Glad to learn there’s a modernised fork (rewrite…?) of the project, though!
Somehow it never occurred to me to look for any… I just accepted defeat and wrote a Bash alias that would recursively clean the current directory, which I still use to this day. I’m definitely interested in trying out Odourless once it’s properly fixed.
1 Like
Thank you!!! Thank you!!! I am so excited. I decided to be brave and do the beta and it lit up my sidebar with lots of pretty icons. And the special bonus…my pdfpen app was showing broken icons everywhere in Monterey/M1 and now it shows an icon of the actual pdf document. I am so happy. Any chance you could fix the rest of my life this perfectly?
1 Like
Hey…wondering if this is in the purview of TotalFinder. It drives me crazy having all the icons in the menubar in a white font. And for that matter, the names of the files on the desktop in a white font. I like black. It’s much easier on my older eyes. Would it be difficult to provide an option to change the font color? Or maybe it’s there already and I just don’t know it…
Again, so don’t understand why Apple doesn’t consider this an accessiblity issues. (I will make a complaint through Feedback…but suspect it’s a waste of time.)
1 Like
YES!!! Finally Finder looks alive on my new Mac Studio!
Thanks so much for all your efforts in maintaining and fixing TotalFinder.
1 Like
As you know, Apple removed custom icons - and all color at all - from the sidebar in macOS 10.7 Lion. As much as I love Steve Jobs, he did have his share of totally DUMB ideas. When Lion was introduced, Jobs said that the color was removed from the sidebar to help users “concentrate”. Imagine that.
So I’m sure there are self-proclaimed UI gurus at Apple who believe they know exactly what users need to “concentrate” - and so they reject any attempt to restore normal icons even as an option.
Quite a few developers submitted requests to restore custom icons via Apple’s Bug Reporter (now Feedback Assistant). Those requests were either ignored or marked as a duplicate of another bug that was marked as ‘closed’.
1 Like