vnop_read does get called for Preview.app for my kext: % sudo dtrace -f 'fbt::vnop_*_myfs/execname!="dtrace"/{}' -odtrace_myfs_preview_image_all_vnops.log 'open -a /System/Applications/Preview.app/Contents/MacOS/Preview /tmp/myfs/Through_the_pines.jpg' % sed -n '/vnop_open/,${s!^[^a-z]*!!;s![^a-z]*$!!p;}' dtrace_myfs_preview_image_all_vnops.log vnop_open_myfs:entry vnop_open_myfs:return vnop_close_myfs:entry vnop_close_myfs:return vnop_inactive_myfs:entry vnop_inactive_myfs:return vnop_getattr_myfs:entry vnop_getattr_myfs:return vnop_setxattr_myfs:entry vnop_setxattr_myfs:return vnop_getxattr_myfs:entry vnop_getxattr_myfs:return vnop_lookup_myfs:entry vnop_lookup_myfs:return vnop_open_myfs:entry vnop_open_myfs:return vnop_close_myfs:entry vnop_close_myfs:return vnop_inactive_myfs:entry vnop_inactive_myfs:return vnop_open_myfs:entry vnop_open_myfs:return vnop_read_myfs:entry vnop_read_myfs:return vnop_mmap_myfs:entry vnop_mmap_myfs:return vnop_close_myfs:entry vnop_close_myfs:return vnop_read returns success: % sudo dtrace -n 'fbt::vnop_read_myfs:entry /execname!="dtrace"/{ self->vnop_read_arg0 = arg0; printf("proc: %s name: %s", execname, stringof(((struct vnop_read_args *)arg0)->a_vp->v_name) ); } fbt::vnop_read_myfs:return /execname!="dtrace" && self->vnop_read_arg0/{ printf("proc: %s name: %s retval: %d", execname, stringof(((struct vnop_read_args *)self->vnop_read_arg0)->a_vp->v_name), arg1 ); }' -odtrace_myfs_preview_image_vnop_read.log 'open -a /System/Applications/Preview.app/Contents/MacOS/Preview /tmp/myfs/Through_the_pines.jpg' % cat dtrace_myfs_preview_image_vnop_read.log CPU ID FUNCTION:NAME 4 146583 vnop_read_myfs:entry proc: Preview name: Through_the_pines.jpg 2 146584 vnop_read_myfs:return proc: Preview name: Through_the_pines.jpg retval: 0 The Preview.app process' state is sleeping: % ps acx | grep -i preview 454 ?? S 0:00.30 Preview The image is not displayed. Incidentally, Google Chrome does succeed in displaying the contents of the image file. The vnops being called seem very similar with vnop_read being called multiple times. % sudo dtrace -f 'fbt::vnop_*_myfs/execname!="dtrace"/{}' -odtrace_myfs_gc_image_all_vnops.log 'open -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome /tmp/myfs/Through_the_pines.jpg' % sed -n '/vnop_open/,${s!^[^a-z]*!!;s![^a-z]*$!!p;}' dtrace_myfs_gc_image_all_vnops.log vnop_open_myfs:entry vnop_open_myfs:return vnop_close_myfs:entry vnop_close_myfs:return vnop_inactive_myfs:entry vnop_inactive_myfs:return vnop_getattr_myfs:entry vnop_getattr_myfs:return vnop_setxattr_myfs:entry vnop_setxattr_myfs:return vnop_lookup_myfs:entry vnop_lookup_myfs:return vnop_getxattr_myfs:entry vnop_getxattr_myfs:return vnop_open_myfs:entry vnop_open_myfs:return vnop_read_myfs:entry vnop_read_myfs:return vnop_read_myfs:entry vnop_read_myfs:return vnop_read_myfs:entry vnop_read_myfs:return vnop_read_myfs:entry vnop_read_myfs:return vnop_close_myfs:entry vnop_close_myfs:return vnop_inactive_myfs:entry vnop_inactive_myfs:return vnop_pathconf_myfs:entry vnop_pathconf_myfs:return vnop_pathconf_myfs:entry vnop_pathconf_myfs:return And returning success at all times. % sudo dtrace -n 'fbt::vnop_read_myfs:entry /execname!="dtrace"/{ self->vnop_read_arg0 = arg0; printf("proc: %s name: %s", execname, stringof(((struct vnop_read_args *)arg0)->a_vp->v_name) ); } fbt::vnop_read_myfs:return /execname!="dtrace" && self->vnop_read_arg0/{ printf("proc: %s name: %s retval: %d", execname, stringof(((struct vnop_read_args *)self->vnop_read_arg0)->a_vp->v_name), arg1 ); }' -odtrace_myfs_gc_image_vnop_read.log 'open -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome /tmp/myfs/Through_the_pines.jpg' % cat dtrace_myfs_gc_image_vnop_read.log CPU ID FUNCTION:NAME 5 144179 vnop_read_myfs:entry proc: Google Chrome name: Through_the_pines.jpg 4 144180 vnop_read_myfs:return proc: Google Chrome name: Through_the_pines.jpg retval: 0 6 144179 vnop_read_myfs:entry proc: Google Chrome name: Through_the_pines.jpg 1 144180 vnop_read_myfs:return proc: Google Chrome name: Through_the_pines.jpg retval: 0 1 144179 vnop_read_myfs:entry proc: Google Chrome name: Through_the_pines.jpg 0 144180 vnop_read_myfs:return proc: Google Chrome name: Through_the_pines.jpg retval: 0 0 144179 vnop_read_myfs:entry proc: Google Chrome name: Through_the_pines.jpg 3 144180 vnop_read_myfs:return proc: Google Chrome name: Through_the_pines.jpg retval: 0 vnop_ioctl is never called for Preview.app or Google Chrome. % grep -c vnop_ioctl dtrace_myfs_*_image_all_vnops.log dtrace_myfs_gc_image_all_vnops.log:0 dtrace_myfs_preview_image_all_vnops.log:0 If you have any other piece of advice for me, it would be greatly appreciated.

Thanks very much for clarifying the proper use of open(1) and for being willing to help. Now, when launching Preview.app through 'open(1) -a' or by double clicking the image file in Finder, Preview.app launches: % open -a /System/Applications/Preview.app/Contents/MacOS/Preview /tmp/myfs/Through_the_pines.jpg lsof(8) reports the image file as being opened by Preview.app: % lsof -p `pgrep -xi preview` | grep Through Preview 2825 developer 3r REG 54,2 2396454 3001938654 /private/tmp/myfs/Through_the_pines.jpg But the contents of the image file aren't being displayed. System logs have the following records: 2024-06-20 09:38:25.821809+0300 0x548e Default 0x0 2823 2 open: (LaunchServices) [com.apple.launchservices:open] Opening document <FSNode 0x600003f790a0> { isDir = n, path = '/private/tmp/myfs/Through_the_pines.jpg' } with application <FSNode 0x600003f79160> { isDir = y, path = '/System/Applications/Preview.app' } 2024-06-20 09:38:26.094972+0300 0x54da Default 0x0 2825 0 Preview: (Foundation) [com.apple.foundation.filecoordination:claims] Read options: 0 -- URL: file:///private/tmp/myfs/Through_the_pines.jpg -- purposeID: 78FD7C2A-102A-4679-A0FE-4854596E124C -- claimID: 2D45E1F1-8533-4F26-ADE7-22E92590C39A The same behaviour is observed with pdf files. As my filesystem is a network one, I thought I'd go and see if https://github.com/apple-oss-distributions/SMBClient offers anythings useful, as opening image and/or pdf files works there. In the meantime, if you have any more tips for me, it would be much appreciated. Is there a specific VFS attribute that meets the system's expectation of a filesystem in terms of sandbox(7) security policies/requirements?

When launching Preview.app on the command line, I get an 'Operation not permitted' error returned. % /System/Applications/Preview.app/Contents/MacOS/Preview /Volumes/myfs/Through_the_pines.jpg 2024-06-17 14:23:16.826 Preview[2745:37915] PVImageContainer initWithURL:file:///Volumes/myfs/Through_the_pines.jpg failed, error = Error Domain=NSCocoaErrorDomain Code=257 "The file “Through_the_pines.jpg” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/Volumes/myfs/Through_the_pines.jpg, NSUnderlyingError=0x6000022302a0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}} File permissions allow reading for all users: % ls -l /Volumes/myfs/Through_the_pines.jpg -rw-rw-r--@ 1 developer staff 2396454 Mar 25 10:48 /Volumes/myfs/Through_the_pines.jpg Am I right in assuming it's sandbox related?

Thanks for replying. I've run stat(1) asynchronously to verify that two processes querying the same file residing on my filesystem get the identical inode value. See below. % stat -f 'inode: %i' t.txt&; stat -f 'inode: %i' t.txt& [1] 1978 [2] 1979 inode: 1954135111 [2] + done stat -f 'inode: %i' t.txt inode: 1954135111 [1] + done stat -f 'inode: %i' t.txt What are the system expectations of a filesystem that my implementation should meet? Is it some struct vfs_attr value that should be set? It has to be something specific, shouldn't it? Is there anything else you could recommend in terms of troubleshooting this? Thanks.