I cannot open files(especially PDF files) after update ventura 13.2.1 to 13.3

Try booting into Safe Mode which clears out caches and performs some other maintenance that can resolve bizarre problems.

On Intel Macs:

1. Shutdown completely
2. Hold Shift key while powering on and keep holding till you get to a login screen
3. Let go and login. You will see a second login screen and it usually says Safe Mode in red on the menu bar at the top.
4. Login again and wait, it will be slower to boot to the desktop. The Dock should have lost its transparency.
5. Give it about 3-5 minutes then shutdown and boot normally

On Apple Silicon Macs:

1. Shutdown completely
2. Press and hold the power button and keep holding it
3. Click on Options and you will see your boot disks Macintosh HD, etc.
4. Hold shift key on the boot drive and it will change to Safe Mode
5. Select and boot macOS
6. There will be two login screens and it should say Safe Mode at the top menu bar
7. The dock transparency will be gone
8. Give it about 3-5 minutes then shutdown and boot normally.

Let us know if the problem persists or not.

Select the file in Finder that you cannot open, press Enter to enter edit mode, and then immediately press Enter again to exit edit mode. Will this open the file? In some cases, you may need to do the same with the full path of the file.

The purpose of this sequence of operations is to convert NFC characters to NFD (editing a file name in Finder converts it to NFD). Apparently, Ventura 13.3 does not equate the filename passed as NFC with the NFD and loses sight of it when the application is launched with the open command or a double-click from Finder.

Well the NFC / NFD Unicode UTF-8-MAC issue is something I've not experienced before.

I did a little research based on @mu-on's comments. The NFC Unicode files likely came from a different operating system and quite possibly from a network share on a Linux based NAS such as a Synology. It's also possible the files are old and came from an older macOS system with JHFS+ filesystem. APFS in Catalina is when the NFD came into play.

Did these files come from another filesystem or server? I know in the past that a BSD / Linux NAS might need to be told to use NFD instead of NFC, etc. Something like a Synology? I found a script to convert to and from NFC / NFD designed to be run on a server like a Synology NAS.

https://github.com/hwdbk/synology-scripts/tree/master/mac-nfd-conversion

There is an interesting and educational discussion about the NFC / NFD problem here:

https://gist.github.com/JamesChevalier/8448512

The problem might continue to re-occur depending on where these files originated. The source of the problem might be the NAS server. Fixing it on the server would be a root cause solution.

I've also found the built-in command line tool called 'iconv' can convert NFC / NFD on macOS. This could fix the files you already have on your Mac that won't open. The command exists on other Linux / Unix systems but doesn't support the option for Mac. But on macOS it does. So something like this:

iconv -f UTF-8 -t UTF-8-MAC <filename>

You could potentially loop that command with a zsh script and a For loop to convert many files.

My initial description of the problem (within Apple support chat):

I have a weird problem with the Finder on my MacBook, it'll take a few lines to explain:

I double klick a file in Finder, e.g. a *.pdf or *.docx or *.jpg.

As usual, the corresponding app opens, e.g. Adobe Reader for pdf, word for docx or the apple ‘preview’ (not sure about the English app name in German it is called Vorschau) for the jpg.

But the file does not appear, the app opens and shows blank.

Re-double-clicking on the file does not change that. The app is running but shows nothing.

If it use the app, so Adobe reader to open that pdf-file from within the app (same for word opening the doc from within word, and the same for the preview app and any other app) then the file gets displayed.

To make it even weirder, not all files are affected, some open when double-clicking, some don't. And it isn't even incoherent within folders, within the same folder some open, some don't. For some folders none of the files open. For other folders there aren’t any problems.

After two chats with apple support and googling and finding this thread I can better describe the problem and the circumstances under which I encounter the problem:

The files and folder structure in question was created on a computer running Windows and synchronised with GoodSync onto a network attached storage (NAS) running samba fileserver protocol. From there, the data was synched onto the MacBook, also using GoodSync. Some of the data has been synched into other shared folders on that NAS (again using GoodSync).

The problem is linked to special characters either in the filename itself or in one of the folders in the file path. As I am German, these typically are the ‘Umlaut’ ä, ö, ü and ß (I didn’t explicitly test whether the ß is also problematic, the ä, ö, ü definitely are). Not every instance when these characters occur in a filename is a problem, but all problematic files have these either in their name or in one of the folder names in their respective path.

However, if I use finder to access the network share and open the problematic files on the share these files came from, there is no problem with opening them through double clicking. Same for the files on the new shared folder, which have been copied from the local files on the MacBook to that network share (as mentioned above, using GoodSync). While the problematic files stored locally on the MacBook do not open through double clicking, their ‘descendants’ on the network share do.

I tried the workaround from mu-on (31-Mar-2023): ‘Select the file in Finder that you cannot open, press Enter to enter edit mode, and then immediately press Enter again to exit edit mode.’ It works! However, sometimes the problem is not the filename itself, but a folder name in the path which has a ‘Umlaut’ ä, ö, ü (and maybe ß). Using the same workaround on the folder name then also solves the problem.

So I fully concur with the deduction by James Brickley (31-Mar-2023) that there is a problem with the transcoding of (at least some) special characters in file- and/or foldernames. And the workaround from mu-on seems to invoke that transcoding for the file (or folder) it is used on.

I am not sure which software is at fault here, which has to handle the transcoding, whether it is macOS when copying the files from/to network shares or - in my case - GoodSync which handles/initiates the copying procedure.

I cannot trace since which Version of macOS this occurred. The ‘recommended solution’ chat entry herein, booting into safe mode, etc. does not help at all.

Greetings from Athens, hope these observations help:

• when an app (Filemaker in my case) creates a .pdf with non-ASCII (Greek) file name on an HFS+ volume, it opens fine
• this applies to other files with long, funny names, say ".ics" calendar files which get opened automatically by the Calendar app
• when the target is an APFS container, they do not open, even when double-clicked on the Finder
• same happens to a Zpool (created by OpenZFSonOSX)

This has been going on since, I believe, the 13.2 or 13.3 update; I'm not entirely sure, but I created a target folder (for the .pdfs and the .ics files) on an HFS+ volume on April 6th to fix the issue, so it was around that time.

This is a definite bug, involving non-ASCII (but proper Unicode) file names, irrespective of character length; I'm pretty sure it will be resolved soon, in the meantime my workaround is to ASCII-ize the file names upon creation (so, say, "Ελλάς.pdf" becomes "Hellas.pdf".

Hope this helps.

With greetings from Athens,

Xen

Have this same problem after updating to version 13.3.1. Files can not be opened straight from Finder or any app. For example Adobe Bridge or even Apples own Archiver app.

Like someone posted it has something to do with special characters in the file names. I solved my problem renaming the root folder. I removed all the special characters from the name. In my case letter ä and a space. After this change all the files in the folder including all the subfolders open normally from the Finder and from the names. I did not change any filenames, only the name of the root folder.

Hope this helps.

13.4 definitely fixes the issue for me, for both existing and newly-created files. A video downloader I use happens to trigger it with the sort of files I download, so I have a large number of files with which to test.

Based on the description of what's fixed--an issue with non-ASCII filenames encoded in a particular way by certain software not opening when double-clicked in the Finder, but otherwise being fine--if you are still having issues, then it seems likely your problem is something different.

You said previously that you were having problems with files that don't have any non-ASCII characters (accents or non-English characters), which points to it being something similar but unrelated anyway. Even with the software I have that is 100% consistent in generating problematic files, if the file has no exotic characters in the name it was fine.

Questions to help narrow down:

Is it only Finder double-clicking and drag-and-drop that doesn't work? If you also can't open the file via the Open menu in the app, it's a different issue.

Does the workaround of editing the filename at all (hit return twice with the file selected is sufficient, even without changing it) fix the problem you're seeing? If so, then it presumably does still have to do with filename encoding; if not, it's something else.

You mentioned PDFs and Office; out of curiosity, is the full path to the files you're having trouble with very long? If the total of all folders and the filename in the path is over 250-some characters in length, some applications will choke and refuse to open files. Microsoft Word and Adobe Acrobat are notorious for this.

If your file's name or your sheet's name contains an accented letter like é, remove the accent. I have reported this glitch to Apple.

Linking another conversation: Issue opening files from Google Drive Fin… - Apple Community

Confirming that this is happening on files coming from other locations, such as Google Drive.

It seems it is happening on files (most probably not only) with UTF-8 encoded diacritics. Example in Czech language: řžýá.docx will result in files not opening, rzya.docx will open fine

Affecting not only Google Drive app but also download - note below, depending on browser.

Reproduction steps for Google Drive:

1) Create a document in Google Drive (web)

2) Name it with diacritics / non-ascii chars

3) Download it as DOCX

4) Try to open the document - Word will launch but will fail to open the file without any error.

5) After the document is renamed (anyhow), open will work just fine.

At the moment, we think this is not a specific Google Drive issue (the same happening at other similar apps we tested, including one we developed).

Also, it's interesting that Safari is not affected (or so it seems). It looks like Safari is doing something that is converting the filename on download.

Example:

Character "í":

1) stored as c3ad in UTF8. This will be how Chrome downloads it if you type this char into document name e.g. in Google Drive and download as DOCX.

2) macOS Ventura 13.3 stores it as 69cc81 (in fact i + ´). This works fine.

It is in Release Candidate stage so it's going to be really soon. I don't know if it will fix this particular bug. But I am hoping it does.

The bug impacts anyone using text with accents in the filenames. Renaming your files will work but can be tedious. Although Finder can mass rename if you highlight multiple files, right-click and choose Rename. Automator can also be used to mass rename as well as command line Unix commands.

I also had the same issue, unable to open the pdf file located in the google drive folder after upgrading to 13.3.

After I ran the disk utility and repaired the disk, I can open the file again.

I see that the problem has been resolved in today's Ventura 13.4. It was a very long waste of "double-enter" period.

In response to Luis Sequeira1's comment that this is "most unlikely to happen with files generated on the mac", I've run into exactly this issue, and can confirm that it absolutely can happen with files generated on the Mac. Maybe not in the vast majority of use cases, but I ran into this myself using nothing but native local apps and it's incredibly annoying.

And it's worth noting that just because English-language users don't often need to deal with file encodings that are prone to this, many Mac users use other languages in filenames regularly.

Specifically: I use Firefox with a video downloader plugin to save streaming videos off the web, nearly all of which are Japanese and have titles that include Kanji that trigger this bug. When I use that to download a file whose title includes more than basic Japanese characters--which I do on a roughly daily basis--as of 13.3 I can no longer double-click the file to open them in VLC unless I touch the filename to get it to re-encode as described elsewhere.

This applies both to hundreds of files that were already on my Mac prior to the 13.3 update, and to all new files the same program generates after the update, which is incredibly annoying.

Hi, Luis. Hope I haven't sent you down a futile path.

I've been trying to troubleshoot this issue using my setup, which includes two OS X machines. The only ".pdf" and ".ics" creator app in both is Filemaker, outputing long names that contain a lot of punctuation and greek lower-case characters. The folder destination has remained the same for a long time.

• System A has been running OS X for 10+ years, currently on 13.3.1 (this way I can examine .pdfs dating back to OS Leopard or so) and outputs .pdfs to an AppleRAID HFS+ volume
• the only issue was that at some point around late March, ".ics" files sent to a ZFS pool (formatted as HFS+) did not open automatically in Calendar app; the workaround was to create ".ics" files with ASCII names
• System B was running Monterey up until a few days ago, and sent ".pdf" files to a user's Documents folder; the volume was obviously APFS
• I upgraded System B from Montery 12.5.2 to Ventura 13.3.1 the day before yesterday, and noted this issue: pdfs would not open, even when double-clicked in the Finder

That brings us to today, when I stumbled on this thread (thank you all!), and noted my observations, as listed above. I realize that my setup is slightly convoluted, but perhaps will be helpful to document the findings.

In any case, thank you for following up, and based on your response I did some more testing:

• created an HFS+ volume in System B (actually a partition within an APFS-formatted disk) and checked to see whether pdfs could be properly opened from there as I had claimed; sure enough they did not, much like what you experienced
• examined the files with the "xattr" terminal command, and realized that the problematic ones only had one metadata attribute: "com.apple.lastuseddate#PS"
• the ones with more attributes, say "com.apple.quarantine" were OK
• I went back to the System A folder holding >30000 pdfs (which all open fine on an HFS+ volume), and there were always one to three xattr attributes listed
• created a test folder in System A's (long-standing Ventura APFS) user folder, and saved a pdf as "Untitled.pdf" and "long-greek-unicode.pdf"
• the ASCII one opened when double-clicked, the one using unicode greek characters did not
• in all cases, the healthy files had more than one xattr attributes, and the problematic ones only "com.apple.lastuseddate#PS"

So, it seems that not having extended file attributes (beyond "com.apple.lastuseddate#PS"), somehow triggers or perhaps is a marker of this problem. My observation re: HFS+ and APFS target folders is, perhaps to some degree, relevant.

It's past midnight around here, and I do not have the resources to troubleshoot this ―I'm a physician managing my office IRL―, but suspect it will be resolved by the mothership team.

With greetings from Athens,

Xen