Bug report FB16082106 submitted. Thanks.

vnode_if.h distributed with Kernel.framework does not define struct vnop_monitor_args: % grep -c 'struct vnop_monitor_args' `xcrun --show-sdk-path`/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/vnode_if.h 0 Because it's defined as a symbol that is private to kernel. Even if I downloaded vnode_if.h from the kernel sources, I wouldn't be able to link against com.apple.kpi.private, would I? All other vnop_name_args structures that aren't defined as kernel private are available in vnode_if.h distributed with Kernel.framework: % awk '/^struct vnop_.*_args/{print $2}' `xcrun --show-sdk-path`/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/vnode_if.h | sort vnop_access_args vnop_advlock_args vnop_allocate_args vnop_blktooff_args vnop_blockmap_args vnop_bwrite_args vnop_clonefile_args vnop_close_args vnop_copyfile_args vnop_create_args vnop_exchange_args vnop_fsync_args vnop_getattr_args vnop_getattrlistbulk_args vnop_getnamedstream_args vnop_getxattr_args vnop_inactive_args vnop_ioctl_args vnop_kqfilt_add_args vnop_kqfilt_remove_args vnop_link_args vnop_listxattr_args vnop_lookup_args vnop_makenamedstream_args vnop_mkdir_args vnop_mknod_args vnop_mmap_args vnop_mmap_check_args vnop_mnomap_args vnop_offtoblk_args vnop_open_args vnop_pagein_args vnop_pageout_args vnop_pathconf_args vnop_read_args vnop_readdir_args vnop_readdirattr_args vnop_readlink_args vnop_reclaim_args vnop_remove_args vnop_removenamedstream_args vnop_removexattr_args vnop_rename_args vnop_renamex_args vnop_revoke_args vnop_rmdir_args vnop_searchfs_args vnop_select_args vnop_setattr_args vnop_setlabel_args vnop_setxattr_args vnop_strategy_args vnop_symlink_args vnop_verify_args vnop_whiteout_args vnop_write_args Samba client is Apple's own implementation, and therefore private symbols are available to it. Which is not the case with the filesystem I'm implementing. Or were you suggesting that there is a way to access those symbols from 3rd party filesystems?

Thanks for a very detailed response. Regrettably, VNOP_MONITOR is off limits to 3rd party filesystems, as it's a XNU_KERNEL_PRIVATE symbol. I'll have to find another way of dealing with this. Thanks.

I've observed the following behaviour both in Finder and on command line with respect to my initial query. In Finder, I have to switch between windows for vnop_getattr() to be called on the parent directory and the filesystem changes made on a different machine to be picked up. On command line, running % ls -ld /parent/directory results in vnop_getattr() to be called and the changes to be picked up. The same behaviour is observed when, e.g., writing files. The file size doesn't get updated in real time. I have to switch between windows for file size changes to be picked up. What am I missing? Thanks.

My filesystem's vnop_rmdir calls cache_purge() and vnode_recycle() on RPC returning success. The v_label associated with the vnode of the directory being removed is set to NULL and free()'d via the vnode_recycle() call path: vnode_recycle()->vnode_drop_and_unlock()->vnode_drop_internal(): vnode_drop_internal: vp->v_label = NULL; if (tmpl) { mac_vnode_label_free(tmpl); } So, client A, residing on machine-a, is still referencing the vnode that just got recycled by client-B residing on machine-b. Seeing that mac_vnode_check_getattrlist() gets called before vnode_getattr() is, which calls my filesystem's vnop_getattr(), how do I make client A, and any other machine with a mount point to my filesystem, become aware of vnodes getting recycled by other clients on the grid?

When dtrace(1)-ing archive extraction over smbfs I overlooked a vnop_pathconf call, which turned out to be the missing link. 0 -> smbfs_vnop_pathconf AUHelperService-1676 -> extractme a_name:10 ;_PC_NAME_CHARS_MAX 0 <- smbfs_vnop_pathconf AUHelperService-1676 -> extractme a_name:10 -> 255 0 -> smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 nameiop:0 0 <- smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 -> 2 ;ENOENT 0 -> smbfs_vnop_lookup AUHelperService-1676 -> TheRooT/extractme/misc 2 nameiop:0 0 <- smbfs_vnop_lookup AUHelperService-1676 -> TheRooT/extractme/misc 2 -> 0 0 -> smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 nameiop:0 0 <- smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 -> 2 0 -> smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 nameiop:0 0 <- smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 -> 2 0 -> smbfs_vnop_lookup AUHelperService-1676 -> extractme.sb-27bcb433-Yj4plp/misc nameiop:0x2 ;DELETE 0 <- smbfs_vnop_lookup AUHelperService-1676 -> extractme.sb-27bcb433-Yj4plp/misc -> 0 0 -> smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 nameiop:0x3 ;RENAME 1 <- smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 -> -2 ;EJUSTRETURN 1 -> smbfs_vnop_lookup AUHelperService-1676 -> extractme.sb-27bcb433-Yj4plp/misc nameiop:0x2 1 <- smbfs_vnop_lookup AUHelperService-1676 -> extractme.sb-27bcb433-Yj4plp/misc -> 0 1 -> smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 nameiop:0x3 2 <- smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 -> -2 2 -> smbfs_vnop_rename AUHelperService-1676 -> extractme.sb-27bcb433-Yj4plp/misc -> extractme/nil 2 <- smbfs_vnop_rename AUHelperService-1676 -> extractme.sb-27bcb433-Yj4plp/misc -> extractme/nil -> 0 1 -> smbfs_vnop_lookup AUHelperService-1676 -> TheRooT/extractme/misc 2 nameiop:0 2 <- smbfs_vnop_lookup AUHelperService-1676 -> TheRooT/extractme/misc 2 -> 0 2 -> smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 nameiop:0 3 <- smbfs_vnop_lookup AUHelperService-1676 -> extractme/misc 2 -> 0 With vnop_pathconf implemented archive extraction over the same directory multiple times on my custom filesystem works as expected. Thanks.

Thanks for your input. No, my filesystem is not based on FUSE. It's a port of a distributed filesystem from a UNIX-like OS to macOS. The original implementation mostly uses locking to protect the RPCs involved in each file operation. On macOS, this doesn't seem sufficient. Thus my query. The Linux kernel documentation for VFS describes the locking rules that must be followed by all filesystems. FreeBSD filesystems extensively employ locking in their VFS implementations. So I assumed that macOS must have its own locking rules for VFS as well. It would be helpful to understand what they are, so my filesystem can adhere to them properly.

Turns out, it was my lookup algorithm that was to blame. Once adjusted as described here rm(1) was no longer complaining and running to completion. Thanks for your help.

Thanks a lot for the tip Kevin. Basic testing does work fine. terminal1: % echo line1 >file.txt terminal1: % ed file.txt ;open file.txt in ed terminal2: % rm file.txt terminal1: % ed file.txt ;close file.txt in ed dtrace output for terminal tests Finder 1. Create file.rtf using TextEdit. 2. Close file.rtf using TextEdit. 3. Open file.rtf using TextEdit. 4. Remove file.rtf via Finder. 5. Close file.rtf using TextEdit. dtrace output for Finder tests Onto a debugging session of rm(1) as you suggested.

Thanks for replying. I had a closer look at the signature of select and realised that there was no way I knew of that I could get a file descriptor to pass into it within the kernel.

Thanks very much for clarifying things, Kevin. Coincidentally, I too was thinking of writing my own tests for the VNOPs implemented. Alexander Kapshuk

Thanks for a prompt response. I disabled local locking and implemented a vnop_advlock of my own. AJAsystemtest issues a POSIX advlock request with vnop_advlock_args.a_flags being set to F_POSIX. What I don't understand is why I'm only getting F_UNLCKs, but no F_SETLKs. A little help clarifying why this is, as well as being pointed in the right direction would be much appreciated.

Passing the smaller value of buf_count and the difference between the file size and the current offset into the file, instead of passing the value returned by buf_count, into myfs_write function fixes the problem. Thanks very much Kevin Elliott for the tip.

For the sake of completeness, with the file reference counter incremented in vnop_mmap, and decremented in vnop_mnomap, image and pdf files are now being properly displayed by Preview.app. Thanks very much Kevin Elliott for all your help.

Thanks a lot for the tip about mmap. With vnop_strategy, vnop_blockmap, vnop_offtoblk, vnop_blktooff, vnop_pagein and vnop_pageout added in, Preview.app is able to read file contents. The idea for the algorithm for computing blockmap, offtoblk and blktooff was borrowed from Apple's open-source SMBClient implementation. However, file memory mapping isn't working as expected. Image files are being displayed properly in part with the rest of the image being garbled. For pdf files, Preview.app displays a message about the file being damaged. I suspect it's probably one or all of blockmap, offtoblk and blktooff that's at fault. If you have any other clues for me, I'd really appreciate that.