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.

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.

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

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

mu-on wrote:

Of course, it is impractical to convert every file name. This is an obvious bug in 13.3 and let's hope it will be fixed in the near future :-)

What James said.

This is most unlikely to happen with files generated on the mac; besides, it would only affect files with names including non-ASCII characters. If you are having problems with files that were already on your mac before the update, it is very unlikely (if not impossible) that the issue is the aforementioned NFC/NFD situation.

13.3 is generally busted.

For example MSO cannot open any recent docs due to the Sandbox: ScopedBookmarkAgent(717) deny(1) file-read-data <path to the file>. Something went utterly wrong with this release.

From GoogleDrive, Safari solves it fine, but from other platforms like Moodle, 
it has some problems. For example, a file named "Gramáticas y Aotómatas.pdf" 
remains as "Gramáticas y Autómatas.pdf", however the Finder can open it.
The worst situation is when using Chrome, where the Finder cannot open the file

In case anybody inside Apple is reading this, you can easily reproduce as follows.

In Terminal:

echo "Hello World" > $(printf "\xc3\xbc").txt

Now try to open "ü.txt", TextEdit will launch, but will fail to resolve the file bookmark due to a sandbox issue.

Failed to resolve bookmark 0x12750ea70 for item F6D82F7E-E34F-4CD8-A7B6-E331894336B8 with error: Error Domain=NSCocoaErrorDomain Code=4

Sandbox: TextEdit(4924) deny(1) file-read-data /Users/iccir/Desktop/ü.txt

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.

James Brickley -- a huge thank you for the technical explanation of this issue, both because I hate having problems and not understanding the cause, and because it saved me attempting a re-install on the assumption that this was some kind of filesystem corruption issue when it's not.

A note, it's entirely possible to end up in this situation without touching a NAS or other external filesystem or server. Specific example, the Video DownloadHelper plugin for Firefox, which does what it says on the tin, will generate files that have this problem if it generates a filename that includes complex characters (in my case, most Japanese kanji, although I was surprised that hiragana doesn't have the issue).

Which I might add are annoying since you now can't double-click the video you just downloaded to play it without touching the filename. It's obviously not that much work to hit return twice, but still annoying.

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.