I've developed a new Quicklook data-based preview extension for a custom file type that generates an image preview of the file. I previously used a Quick Look generator plug-in but support for it was deprecated and now removed in macOS Sequoia.
My app opens files using a
open(url.path, O_RDWR | O_NONBLOCK | O_EXLOCK)
call. The locking flags are used to prevent other clients from writing the file if it's already open.
I discovered that when Finder is showing the “large” file previews (such as when in column or gallery modes) from a SMB share, the open call fails with EWOULDBLOCK as if the file is locked.
It does work just fine on local files. Opening with O_SHLOCK also has the issue. Surprisingly it does work just fine for previews that return Plain Text data instead of Image data.
Using the lsof command, it seems like the Quicklook process has some kind of lock on the file.
This is the output of the lsof command:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE
QuickLook 48487 XXXX txt REG 1,15 125000611 3161369
Attached is a test project that tries a few different opening and locking functions. It also includes a test file and a sample image preview extension that displays a red square.
When everything is working, regular console messages show the progress of the tests. When the file is on a SMB share and selected in Finder Gallery mode, the open test will fail with a fault message in the console.
Notably, locking with flock works, which is weird because it should have similar semantics according to the man page for open(2).
Filed this as FB15051186