I've been looking at the new kernel caching APIs in FSKit (FSVolume.DataCacheHandler), and they look like they'll be quite useful for network file systems. But are they recommended to be implemented for block device file systems? I see an "Important" note in the documentation that says If a file system doesn’t conform to this protocol, the kernel may still cache it. However, such a file system has no control over caching behavior; the kernel caches data as it sees fit. So I'm wondering in the case of a block device system, where I'm (mostly) using kernel offloaded IO, whether this has any relevance, or if I should instead skip this implementation and just let the kernel "do its thing."

Can the new FSClient.mountSingleVolume along with the com.apple.developer.fskit.mount entitlement be used to mount a block device resource from a sandboxed GUI app? I ask since FSBlockDeviceResource doesn’t seem to have a public initializer other than init(coder:) and using Disk Arbitration (e.g. DADiskMount or DADiskMountWithArguments) has been finicky with the App Sandbox (FB16728800). I'm interested in making an easy workaround e.g. for users who have an internal partition supported by my file system extension that isn't automounting (FB21729650).

I have a file system extension that currently uses the various now-deprecated Operations protocols. I have a few questions about moving to the new Handler protocols. First, my module is going to maintain backwards compatibility with macOS Sequoia for the foreseeable future, but I would also like to be able to take advantage of new FSKit features for users who are on newer OS versions. What approach would you recommend: Having an FSVolume conform to both the various Operations and Handler protocols (e.g. both FSVolumeKernelOffloadedIOOperations and FSVolume.KernelOffloadedIOHandler with the latter tagged with @available) an immediate issue I see trying to do this is I run into the error Method 'activate(options:)' with Objective-C selector 'activateWithOptions:replyHandler:' conflicts with previous declaration with the same Objective-C selector when trying to conform to both FSVolume.Handler and FSVolume.Operations. Having two separate FSVolume implementations, one used for older OS versions with Operations support and one used on newer OS versions with Handler support? Keeping the use of pre-existing Operations protocols while only using the Handlers for newer features (e.g. things like SeekRegionHandler) Second, I see at https://developer.apple.com/documentation/fskit/fsvolumehandlerresult/requestedattributes that I must populate all requested attributes. Does this value only have a meaning if the initializer for the actual concrete result type has an initializer that takes in a FSItem.Attributes instance, or is there some way I’m supposed to populate those? (As a concrete example, FSCheckAccessResult has init(accessAllowed:) which doesn’t take in any attributes.)

When implementing kernel offloaded IO, FSExtentType.zeroFill (https://developer.apple.com/documentation/fskit/fsextenttype/zerofill) indicates it should only be used for sparse files to represent ranges that haven’t been allocated yet. What if I have ranges that have been allocated disk space but not yet zeroed out, and have some kind of marker that indicates that those ranges aren’t initialized (and thus should be interpreted as zeroes)? Is it fine to use zeroFill to represent this case?

Is FSBlockDeviceResource thread-safe, or do I need to ensure that it’s not written across multiple threads simultaneously? I see that FSBlockDeviceResource is not marked as Sendable in Swift. (This question could also apply to the other FSResources as well if it's simple to answer for them too, but it's just that for my specific use case I'm using FSBlockDeviceResource.)

Is it necessary to switch to the new FSExtentType.readOnly when implementing kernel offloaded IO if my entire volume is read-only and marked as such via requestedMountOptions? (My assumption is "no" since I'd think all writes to the resource at that point should be prevented anyway, but wanted to ask just in case.)

As the title says, I'd like to run a macOS 27 VM on my Mac (the host is on macOS 26.5.1) in order to test my apps without having to update my host to a beta. My virtualization app of choice (VirtualBuddy) fails on installation when I use the restore image for macOS 27.0 (26A5353q) from the developer website. The developer of VirtualBuddy believes this is a macOS limitation (https://github.com/insidegui/VirtualBuddy/discussions/683). (I filed FB22977958, but I'm not sure if they filed their own bug.) Is there a workaround? It'd be very nice to have access to this during WWDC week. Usually I'd look for device support files on the developer website for download and/or install the Xcode beta first, but I've already installed the Xcode beta and there don't seem to be any device support files available.

The developer documentation for Rosetta describing its end of support (https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment) says the following: Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks. Are there details about which specific functionality this is? And as a concrete example, will parts of Rosetta that are needed by programs used to run and/or evaluate Windows games, such as WINE or CrossOver, remain supported?

If you have a "launcher-type app" (a regular macOS app bundle) which is used to launch the actual game executable (a non-bundled executable, such as a Java game), Game Mode does not seem to work as desired in this case. If the launcher app has the appropriate LSSupportsGameMode and LSApplicationCategoryType set, the launcher app will activate Game Mode if fullscreened but the actual game will not (FB18026957). Is there a workaround for this? It also seems like the system hardcodes some apps to act as "game launcher apps" which do have the desired behavior - for example, if you have a sample app set to Steam's bundle identifier (or just use Steam to run the program) and have this architecture where it runs another executable which is the real game, then that game can inherit Game Mode, which is also supported by system logs in Console (note the "launcher" labelReason): default 17:11:05.008533-0400 gamepolicyd Found game GameProcess(Optional("java"), pid=33754, euid=501, labelReason=launcher, launchedBy=Steam) Is there a way to opt into or apply for this behavior for our own apps? I previously asked this on the forums but I'm also wondering if any new developments have occurred since then.

I'm writing a read-only filesystem extension. I see that the documentation for loadResource(resource:options:replyHandler:) claims that the --rdonly option is supported, which suggests that this should be possible. However, I have never seen this option provided to my filesystem extension, even if I return usableButLimited as a probe result (where it doesn't mount at all - FB19241327) or pass the -r or -o rdonly options to the mount(8) command. Instead I see those options on the volume's activate call. But other than saving that "readonly" state (which, in my case, is always the case) and then throwing on all write-related calls I'm not sure how to actually mark the filesystem as "read-only." Without such an indicator, the user is still offered the option to do things like trash items in Finder (although of course those operations do not succeed since I throw an EROFS error in the relevant calls). It also seems like the FSKit extensions that come with the system handle read-only strangely as well. For example, for a FAT32 filesystem, if I mount it like mount -r -F -t msdos /dev/disk15s1 /tmp/mnt Then it acts... weirdly. For example, Finder doesn't know that the volume is read-only, and lets me do some operations like making new folders, although they never actually get written to disk. Writing may or may not lead to errors and/or the change just disappearing immediately (or later), which is pretty much what I'm seeing in my own filesystem extension. If I remove the -F option (thus using the kernel extension version of msdos), this doesn't happen. Are read-only filesystems currently supported by FSKit? The fact that extensions like Apple's own msdos also seem to act weirdly makes me think this is just a current FSKit limitation, although maybe I'm missing something. It's not necessarily a hard blocker given that I can prevent writes from happening in my FSKit module code (or, in my case, just not implement such features at all), but it does make for a strange experience. (I reported this as FB21068845, although I'm mostly asking here because I'm not 100% sure this is not just me missing something.)

If I'm in an enumerateDirectory call, I can very quickly fill in the fileID, parentID, and (maybe) the type attributes based on the directory entry I have loaded. That is, I can quickly fill in anything that is contained in the dirent structure in dirent.h, plus the parentID. However, if any other attributes are requested (say, flags), or if the file system doesn't store the filetype in the directory entry, then I need to do additional I/O and load an inode. If I have to load an inode, I might keep a reference to it and assume that I can clean it up later whenever there is a matching call to reclaimItem. But in the enumerateDirectory call, I never provide an FSItem to the system! By observation, I see that normally, a call to enumerateDirectory of this nature is followed up by a lookupItem call for every single fetched item, and then assumedly the system can later reclaim it if need be. At least, I tried various ways of listing directories, and each way I tried showed this behavior. If that's the case, then I can rely on a later reclaimItem call telling me when to clean up this cached data from memory. Is this guaranteed, however? I don't see a mention of this in the documentation, so I'm not sure if I can rely on this. Or, do I need to handle a case where, if I do additional I/O after enumerateDirectory, I might need to figure out when cached data should be cleaned up to avoid a "leak?" (Using the term "leak" loosely here, since in theory looking up the file later would make it reclaimable, but perhaps that might not happen.)

I'm trying to test the update process for an app containing an FSKit module that I'm distributing on the Mac App Store. (I'm also distributing the same app directly with Developer ID, but here I'll focus on App Store because that's the behavior I've been looking at first.) To do that I'm using an internal tester group on TestFlight and then testing an update with TestFlight. Below is the behavior I'm seeing on macOS 15.7.2 (24G325). I've noticed that if an app update is triggered while a disk is mounted using the FSKit extension, the disk is automatically unmounted without warning (FB21287341). That's already undesirable itself in my opinion, but on top of the unmount, there are two other problems: That unmount doesn't seem to be a "clean" unmount and doesn't call functions like synchronize (FB21287688). Now, in my case, my app only provides read-only access, so that doesn't actually matter much in my case. However, I'd imagine if I were to add write access at some point in the future, this would go from "doesn't matter" to "very bad." I've seen a few cases where quitting or crashing the FSModule process while a volume is mounted without actually doing a clean unmount causes a lot of "disk-related actions" (for lack of a better term) to freeze (FB21305906). For example, a use of the mount(8) command or trying to mount a disk at all freezes, and opening Disk Utility stalls on a "Loading disks" spinning indicator. This happens until the Mac is rebooted. I did notice this issue once while testing updates via TestFlight a few times. The same applies if I simply delete the app with Finder instead of updating it. Is there a way to prevent the extension's process from terminating in this case and/or another workaround I could use without waiting for a macOS update to hopefully change this behavior? And does observing this kind of behavior with TestFlight's update behavior suggest the same thing could happen on the App Store with its automatic updates? I'm concerned that pushing an update via the App Store will unexpectedly unmount disks or cause the system-wide issues described in FB21305906 at a random time, which is a pretty big disruption for users.

I often use a Wi-Fi network where: Whatever mechanism Xcode uses to automatically discover a previously paired iOS device seems to be blocked (the Devices and Simulators window shows "Browsing on the local area network for [iPhone]" and never proceeds), but I can connect to the iOS device from my Mac if I know its IP address, such as by pinging it The same hardware/software configuration works with wireless Xcode connections on a different Wi-Fi network. Thus I'm wondering if there's any functionality that allows the IP address to be manually entered into Xcode to avoid needing to connect a cable from my Mac to my iPhone during development. Searching around seems to suggest this existed at some point in the past but I can no longer find this in a current version of Xcode. Or if there are any other workarounds, although I can't modify the network itself as it's not my network.

I've gotten to the point where I can use the mount(8) command line tool and the -t option to mount a file system using my FSKit file system extension, in which case I can see a process for my extension launch, probe, and perform the other necessary actions. However, when plugging in my USB flash drive or trying to mount with diskutil mount, the file system does not mount: $ diskutil mount disk20s3 Volume on disk20s3 failed to mount If you think the volume is supported but damaged, try the "readOnly" option $ diskutil mount readOnly disk20s3 Volume on disk20s3 failed to mount If you think the volume is supported but damaged, try the "readOnly" option Initially I thought it would be enough to just implement probeExtension(resource:replyHandler:) and the system would handle the rest, but this doesn't seem to be the case. Even a trivial implementation that always returns .usable doesn't cause the system to use my FSModule, even though I've enabled my extension in System Settings > General > Login Items & Extensions > File System Extensions. From looking at some of the open source msdos and Disk Arb code, it seems like my app extension needs to list FSMediaTypes to probe. I eventually tried putting this in my Info.plist of the app extension: <key>FSMediaTypes</key> <dict> <key>EBD0A0A2-B9E5-4433-87C0-68B6B72699C7</key> <dict> <key>FSMediaProperties</key> <dict> <key>Content Hint</key> <string>EBD0A0A2-B9E5-4433-87C0-68B6B72699C7</string> <key>Leaf</key> <true/> </dict> </dict> <key>0FC63DAF-8483-4772-8E79-3D69D8477DE4</key> <dict> <key>FSMediaProperties</key> <dict> <key>Content Hint</key> <string>0FC63DAF-8483-4772-8E79-3D69D8477DE4</string> <key>Leaf</key> <true/> </dict> </dict> <key>Whole</key> <dict> <key>FSMediaProperties</key> <dict> <key>Leaf</key> <true/> <key>Whole</key> <true/> </dict> </dict> <key>ext4</key> <dict> <key>FSMediaProperties</key> <dict> <key>Content Hint</key> <string>ext4</string> <key>Leaf</key> <true/> </dict> </dict> </dict> </plist> (For reference, the partition represented by disk20s3 has a Content Hint of 0FC63DAF-8483-4772-8E79-3D69D8477DE4 and Leaf is True which I verified using IORegistryExplorer.app from the Xcode additional tools.) Looking in Console it does appear now that the system is trying to use my module (ExtendFS_fskit) to probe when I plug in my USB drive, but I never see a process for my extension actually launch when trying to attach to it from Xcode by name (unlike when I use mount(8), where I can do this). However I do see a Can't find the extension for <private> error which I'm not sure is related but does sound like the system can't find the extension for some reason. The below messages are when filtering for "FSKit": default 19:14:53.455826-0400 diskarbitrationd probed disk, id = /dev/disk20s3, with ExtendFS_fskit, ongoing. default 19:14:53.456038-0400 fskitd Incomming connection, entitled 1 default 19:14:53.456064-0400 fskitd [0x7d4172e40] activating connection: mach=false listener=false peer=true name=com.apple.filesystems.fskitd.peer[350].0x7d4172e40 default 19:14:53.456123-0400 fskitd Hello FSClient! entitlement yes default 19:14:53.455902-0400 diskarbitrationd [0x7461d8dc0] activating connection: mach=true listener=false peer=false name=com.apple.filesystems.fskitd default 19:14:53.456151-0400 diskarbitrationd Setting remote protocol to all XPC default 19:14:53.456398-0400 fskitd About to get current agent for 501 default 19:14:53.457185-0400 diskarbitrationd probed disk, id = /dev/disk20s3, with ExtendFS_fskit, failure. error 19:14:53.456963-0400 fskitd -[fskitdXPCServer applyResource:targetBundle:instanceID:initiatorAuditToken:authorizingAuditToken:isProbe:usingBlock:]: Can't find the extension for <private> (I only see these messages after plugging my USB drive in. When running diskutil mount, I see no messages in the console when filtering by FSKit, diskarbitrationd, or ExtendFS afterward. It just fails.) Is there a step I'm missing to get this to work, or would this be an FSKit bug/current limitation?

I reported this as a bug (FB18614667), but also wanted to ask here in case this is actually just me doing something wrong, or maybe I'm misunderstanding the entire use case of metadataRead. (My understanding is that metadataRead is basically read but it checks a cache that the kernel manages before trying to read the physical resource, and in the case of a cache miss it would just go to the physical resource and then add the bytes to the cache. Is that right?) I’m encountering an issue in an FSKit file system extension where (for example) read(into: buf, startingAt: 0, length: Int(physicalBlockSize)) works, but metadataRead(into: buf, startingAt: 0, length: Int(physicalBlockSize)) throws an EIO error (Input/output error) no matter what I do. (Note: physicalBlockSize is 512 in this example.) The documentation (https://developer.apple.com/documentation/fskit/fsblockdeviceresource/metadataread(into:startingat:length:)) indicates that the restrictions on metadataRead are that the operations must be sector-addressed (which is the case here, especially as regular read has the same restriction and succeeds) and that partial reading of metadata is not supported. (I don’t think that applies here?) In a sample project I was able to replicate this behavior where the module only ever reads the block device in its enumerateDirectory implementation, and so trying to list the contents of a directory leads to an "Input/output error" when e.g. running ls on the volume. The enumerateDirectory sample implementation is like so: func enumerateDirectory(_ directory: FSItem, startingAt cookie: FSDirectoryCookie, verifier: FSDirectoryVerifier, attributes: FSItem.GetAttributesRequest?, packer: FSDirectoryEntryPacker) async throws -> FSDirectoryVerifier { let buf = UnsafeMutableRawBufferPointer.allocate(byteCount: Int(blockDevice.physicalBlockSize), alignment: 1) defer { buf.deallocate() } // metadataRead will throw... try blockDevice.metadataRead(into: buf, startingAt: 0, length: Int(blockDevice.physicalBlockSize)) // but read will work. // try await blockDevice.read(into: buf, startingAt: 0, length: Int(blockDevice.physicalBlockSize)) // ... return dummy file here (won't reach this point because metadataRead throws) } I'm observing this behavior on both macOS 15.5 (24F74) and macOS 15.6 beta 3 (24G5074c). Has anyone been able to get metadataRead to work? I see it used in Apple's msdos FSKit implementation so it seems like it has to work at some level.