Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Makosuke

macrumors 604
Original poster
Aug 15, 2001
6,818
1,550
The Cool Part of CA, USA
After installing the macOS 13.3 update I'm suddenly having an absolutely bizarre problem on my M1 Max MBP: Files whose filenames contain most Japanese kanji characters won't open in the associated program when double clicked unless I edit the filename.

For the problem files, when I double-click on it in the Finder, the Finder does the open animation and the associated app opens, but the file does not. The app just sits there like I hadn't clicked anything. Dragging the file to the app's icon does the same thing--it accepts the drop but nothing opens. If I manually open the file from within the application (via an "Open" dialogue), it opens fine.

Rebooting, moving the file or its parent folder, or renaming the parent folder did not make any difference, nor did modifying the default "open with" program for the file or its file type. What does fix it is editing the filename, at all, even if nothing at all is changed. Even just selecting the file, hitting return to put the filename into edit, then hitting return again without touching anything will restore normal behavior.

I've experimented with a bunch, and it's not just non-English filenames or filenames of a certain length; files with all English characters and some with just a couple of simple kanji all seem to open normally, but files with anything more than a couple of kanji (some of which are relatively short--less than 32 characters) all fail.

Figuring directory corruption, I rebooted in Recovery Mode and ran Disk Utility's First Aid on the Data volume and got a bunch of "warning: inode (...): dir-stats key xf does not exist, despite internal_flags (0x8412)" messages, which apparently repaired successfully and it now checks without throwing any errors or warnings... but the behavior remains.

I'm not excited about wiping and reformatting the whole thing since otherwise it seems okay, nor do I particularly want to have to touch hundreds of files, so I'm wondering if anybody has seen something similar or has any suggestions before I go nuclear.

Possibly related: After doing that update, all of the Touch ID fingerprints also disappeared. I was able to recreate new ones without issue, but have never had that happen before.
 
I have exactly same problem. I've also noticed that if I move the files to external SMB share on a NAS they play fine when opening via Finder. This must be a recent bug - wonder if it is still there in 13.4 betas?
 
This isn't a font issue, the filenames actually display fine; it turns out to be a text encoding issue, as described below.

I have exactly same problem. I've also noticed that if I move the files to external SMB share on a NAS they play fine when opening via Finder. This must be a recent bug - wonder if it is still there in 13.4 betas?
Someone in the Apple forums explained what the cause of this is--apparently there are two ways that UTF-8 filenames can be UTF-8 encoded, NFC and NFD. The former is unusual on macOS, but can (obviously) happen in some cases (in my case a cross-platform tool), and up until 13.3 worked fine. Apparently in 13.3, something gets goofed up when the Finder tries to pass the filename to the app, so it dies.

This is why editing the filename or even just touching it (hitting return twice) fixes it--it presumably causes the Finder to re-encode the filename using NFD, which fixes it.

I'll add that moving the files is the same as any other copy action, it's going to re-encode the filename in the "good" format. So even just duplicating them on disk will resolve it with the dup.

The useful bit if info, though, is that it's not filesystem corruption, so reinstalling won't fix anything. I haven't tried a 13.4 beta, but 13.3.1 didn't fix it.
 
  • Like
Reactions: Donza
This has been driving me crazy.
For some reason, it only happens with some Excel files.
 
So happy to come across this thread! This has been bugging me for a while now. It took me a while to nail it down because it was happening in PDF files with "é" in the name. I figured out that changing the é to e made it open, and just a few minutes ago realized I could make *any* change and they also opened. And here you all are with the solution. Thanks, everybody! Much appreciated. Keep kicking butt.
 
Just for definitive confirmation: This is fixed in the release version of 13.4. Install it and everything is back to the way it should be.

Although I have to admit: Now that I realize there are at least two subtly different ways text can be encoded in file paths, something vaguely bugs me about it, like if I had a handful of text documents that were encoded in Shift-JIS instead of Unicode but had absolutely no way to know.
 
  • Like
Reactions: Donza
Yes, working for me as well.
What a tedious bug this was, can't believe Apple didn't fixed it sooner.
 
Eh, they fixed it in the next point-update, which took about 6 weeks; that's about as quickly as Apple fixes anything other than really severe bugs or major security flaws.

This was incredibly annoying, but in the grand scheme it really didn't take that long and it affected a comparatively small number of people since from the sound of it very few pieces of software generate whatever the problematic encoding method is.
 
Just for definitive confirmation: This is fixed in the release version of 13.4. Install it and everything is back to the way it should be.

Has anyone noticed this is back? I don't know if it's exactly the same issue, but seems like it. Problems with such encodings on a Synology NAS and accessed through the Finder on MacOS 15.x. Have to manually rename files to get them to copy, move, open, etc.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.