Lastly, and this is happens a lot with VFS drivers, the answer to "why doesn't it work for me?" is almost always "because you are NOT in fact doing the same thing". The VFS system is riddled with details and edge cases where small differences end up breaking things. That's also why I can't tell you "here's what's wrong". I'd have a hard time even coming up with a list of possible failures, much less guessing at which one went "wrong".
I think I've finally understood what you are trying to say. Each case is unique, and trying to do what other filesystems do may or may not help us, so it's not the perfect solution to simply mimic everything.
Have you looked at what ioctl calls you're getting (if any)? Of everything you've said, this is the one that I was immediately most concerned about. I'm pretty sure it's also NOT something FUSE does.
Yes, I did check the ioctl commands. For Sonoma, there are only two vnop_ioctl calls. The debug message by me:
-
VNOP_IOCTL ENTRANCE, a_command HEX [0x40046812] DECIMAL [1074030610]
-
VNOP_IOCTL ENTRANCE, a_command HEX [0x40046813] DECIMAL [1074030611]
From what I've found, those commands are mentioned is OpenZFS as
SPOTLIGHT_IOC_GET_MOUNT_TIME
https://github.com/openzfsonosx/openzfs/blob/development/include/os/macos/zfs/sys/zfs_vnops_os.h#L48
and SPOTLIGHT_IOC_GET_LAST_MTIME
https://github.com/openzfsonosx/openzfs/blob/development/include/os/macos/zfs/sys/zfs_vnops_os.h#L51
However, if we talk about Monterey, there are hundreds of calls to vnop_ioctl. However, grouping them up has shown, that there are only four unique calls :
- Once, previously discovered
VNOP_IOCTL ENTRANCE, a_command HEX [0x40046812] DECIMAL [1074030610] (SPOTLIGHT_IOC_GET_MOUNT_TIME)
- Once, previously discovered
VNOP_IOCTL ENTRANCE, a_command HEX [0x40046813] DECIMAL [1074030611] (SPOTLIGHT_IOC_GET_LAST_MTIME)
- Unidentified command, called hundreds of times
VNOP_IOCTL ENTRANCE, a_command HEX [0x40084A4A] DECIMAL [1074285130]
- Another unidentified command, also called hundreds of times
VNOP_IOCTL ENTRANCE, a_command HEX [0x40044A48] DECIMAL [1074022984]
What did your file system say it supported? All the ones you listed were local and most local file system don't support searchfs because it's easier just to let spotlight do it's thing. It was created for network file systems, where the spotlight approach just isn't a good idea.
The thing is, the vnop_searchfs is never called. And I couldn't find the reason for it.
To stop blindly shooting, I will give some useful information about my vfs.
- mount flags (always the same, set in code):
#define MNT_FLAGS (MNT_NOEXEC|MNT_NOSUID|MNT_NODEV|MNT_IGNORE_OWNERSHIP|MNT_NOATIME|MNT_NOBLOCK /|MNT_LOCAL|MNT_DOVOLFS/);
vfs_setflags(fsmount, MNT_FLAGS);
MNT_LOCAL and MNT_DOVOLFS were turned off by your note and for testing purposes.
-
VFS operations supported
.vfs_start
.vfs_mount
.vfs_unmount
.vfs_root
.vfs_getattr
.vfs_setattr
.vfs_sync
.vfs_vget
-
Supported attributes
3.1 Capabilities format
| VOL_CAP_FMT_SYMBOLICLINKS
| VOL_CAP_FMT_HARDLINKS
| VOL_CAP_FMT_CASE_SENSITIVE
| VOL_CAP_FMT_CASE_PRESERVING
| VOL_CAP_FMT_2TB_FILESIZE
| VOL_CAP_FMT_PATH_FROM_ID
| VOL_CAP_INT_SEARCHFS
3.2 Capabilities interfaces
| VOL_CAP_INT_ATTRLIST
| VOL_CAP_INT_VOL_RENAME
| VOL_CAP_INT_FLOCK
| VOL_CAP_INT_EXTENDED_ATTR
3.3. Common attr
| ATTR_CMN_FSID
| ATTR_CMN_FILEID
| ATTR_CMN_OBJTYPE
| ATTR_CMN_FNDRINFO
3.4. Volattr
| ATTR_VOL_NAME
| ATTR_VOL_MOUNTFLAGS
| ATTR_VOL_ATTRIBUTES
| ATTR_VOL_IOBLOCKSIZE
| ATTR_VOL_CAPABILITIES
3.5. DirAttr, FileAttr, ForkAttr, are 0.
- Supported vnops
vnop_getattr_desc
vnop_setattr_desc
vnop_lookup_desc
vnop_open_desc
vnop_close_desc
vnop_read_desc
vnop_write_desc
vnop_readdir_desc
vnop_mkdir_desc
vnop_rmdir_desc
vnop_create_desc
vnop_remove_desc
vnop_rename_desc
vnop_mmap_desc
vnop_mnomap_desc
vnop_reclaim_desc
vnop_fsync_desc
#if 0 // TODO: vnop_link incomplete. To be revisited at a later time
vnop_link_desc
#endif
vnop_symlink_desc
vnop_readlink_desc
vnop_getxattr_desc
vnop_setxattr_desc
vnop_listxattr_desc
vnop_removexattr_desc
vnop_ioctl_desc // debug only
vnop_searchfs_desc // debug only
*vnop_ioctl and vnop_searchfs are realised like
{
LOG(VNOP_[IOCTL/SEARCHFS] Entrance...);
return KERN_SUCCESS;
}
**As mentioned, vnop_searchfs isn't called at any time on any OS.
I'm sorry for large context, but I think that will be more useful . Thank you for your patience.