File Systems Q&A

macOS has the clonefile*() calls to create a new file that's a clone of an existing file, but is it possible to clone only parts of an existing file into a different existing file? Linux (FICLONERANGE) and Windows (FSCTL_DUPLICATE_EXTENTS_TO_FILE) both provide this functionality. I previously filed FB12737014 with this request.

There is an API in NSFilePresenter called primaryPresentedItemURL. It is implemented on macOS, but not iOS or Catalyst. I want to use it to write an XMP sidecar file next to original image files. However, because it’s not implemented on iOS or Catalyst, I cannot do this. The only workaround I have found is to ask the user for access to the whole folder. This, of course, is bad from a user privacy / security standpoint, especially as it gives the app access not only to the folder contents, but all subfolders. Can you give me a better workaround, or implement the API on iOS and Catalyst? Feedback Number is FB22771292

What is the recommended way to determine whether an item can be moved to Finder Trash on a given volume? If no Trash directory is available, is user confirmation followed by immediate deletion the expected path? For which common volume types is a Trash directory unavailable? Thanks!

Any plans to provide (a subset of) the FUSE3 API directly on top of FSKit/an underlying primitive, in a way that doesn't compromise the new security model, but also reduces porting friction?

Hi folks! I’ve been paying attention to FSKit for moment to develop a network file system designed for source control-use cases (à la Eden or Google’s CITC). The design goal is support instant clones, even of massive repositories, by lazily fetching files as needed. Based on this thread, it seems like macOS 27 has added some of the requisite APIs needed to support inode invalidation for network/shared file systems like the cache coherency APIs. For example, I’m thinking that for this file system, I’d want to bypass the kernel’s own caching and have my file system be entirely responsible for it, as it‘d have a better understanding/picture of what is up-to-date and what isn’t and there won’t need to be multiple layers of cache invalidation/coherency. Am I correctly reading the intent of these new APIs?

hello dear Apple developers I have a couple of questions one what do I really need to get into your team ? And if you had extra time what kind of program would you make? please tell us I really appreciate you. Have a nice day.

Hi all, Every year about 20 or 30 fee-paying developers attempt to notarize their mac apps and during the process they get a rejection response that says "Status Code 7000: Team ID not yet configured for notarization." No one has ever been able to get their team ID configured for notarization if they get hit by the 7000 status code error. Every month we get 5 or 6 new posts by people saying they got hit with it, and NEVER once has anyone posted a follow-up that they had the issue resolved. As Apple Engineers, can you provide any insight into this problem?

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."

Outside of a very narrow happy path, Filesystem Extensions can leave the system in a bad state that can be hard to get out of: For example, a hanging Volume call can leave any process attempting to read from it permanently stuck (no timeouts, process is unkillable, ps / pkill / pgrep themselves may start hanging). When it comes to installation, FS AppEx are registered with two subsystems afaict (LaunchServices and fskitd) — those two states can get out of sync, and typically cannot be repaired manually. In particular, the only way to reset fskit state seems to be to kill it (notably, disabling SIP is required to launchctl kickstart it, but sudo killall fskit works like a charm). AppEx installed/enabled state seems to be per-user. When mounting as root, fskit queries a different state (implying that a FS may be enabled for an admin user ie. John Doe, but not from the perspective of a root SMAppService — even when using launchctl asuser/bsexec to attempt to replicate the security context of John Doe's login session at their behest). The actual question here is hard to formulate... are there any plans to make FS AppEx behave more like the rest of the platform? More consistent/helpful/centralized logging (it is currently spread across multiple targets and as much as the "boom" and emojis are entertaining, on day 14 of debugging transient failures, it does get old). Making a .pkg installer with an FS AppEx inside prevents the AppEx from being installed through the prescribed happy path (simply having the user launch the containing .app) since it gets pre-registered via LaunchServices. In fact, building an AppEx through XCode automatically registers it with ls, making real-world testing of AppEx really difficult... The sheer breadth of subtle challenges in shipping a working, reliable FSKit-based filesystem on macOS has prevented me so far from filing tidy, individual bug reports, and for this I apologize, but: if you have a roadmap of "reliability improvements / behavior normalization / edge case resolutions" to share today, I'm sure many of us would be eager to read it.

Should currentSyncAnchor(completionHandler:) return a global version number of the backend, or one scoped to the enumerator's container identifier? What should we return if the backend has no per-container version? Also, how does the system use this anchor? It appears to be followed by enumerateItems(for:startingAt:), but nothing seems to guarantee the anchor hasn't changed in between. Is there an atomicity expectation here?

What is URLResourceKey.documentIdentifierKey intended to identify compared with fileIdentifierKey? Is it expected to persist across save/replace operations, rename, move, app relaunch, or unmount/remount? Thanks!

In my sandboxed app, if a bookmarked network source is unavailable, is resolving the source/root security-scoped bookmark the recommended way to way to trigger a remount of the network volume? Thanks!

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).

Any chances of URL-style mounts (myfs://blah) being back ported to macOS 15? They have several upsides compared to volume-based mounts (/tmp/my-fake-vol.dmg => /dev/disk4 => /Volumes/my-vfs) including unprivileged mounts, but also, it feels a bit early still to set a minimum requirement of macOS 26 for end-user applications.

For network volumes where volumeUUIDStringKey is nil, is there any other stable volume/share identifier suitable for namespacing file IDs? More generally, what should I use as the volume identity component when persisting file identifiers for network files? If volumeSupportsPersistentIDsKey == true on a network volume, can fileIdentifierKey / systemFileNumber be expected to survive unmount/remount, reconnect, and server restart? Does fileIdentifierKey on network volumes represent the same kind of filesystem identity as it does on local/removable volumes? Thanks!

I have a UGreen NAS. My app can read the contents of a folder on the NAS from macOS, but it cannot read the contents of a folder from iOS. I bring up a UIDocumentPickerViewController(forOpeningContentTypes: [UTType.folder], asCopy: false). I can pick a folder on the iPad’s internal storage, and successfully enumerate its contents. On the UGreen, I can pick a folder, but the content enumeration always returns zero items (no errors). Enumeration of the UGreen works from macOS. It also works on the iPad when connecting to a Mac mini, or a Synology NAS. . Files.app is able to view the UGreen folder and its contents. Oddly, my app cannot enumerate the contents, but it IS able to write a file to that UGreen folder. Since Files.app can enumerate and I can write to the UGreen folder (and I can enumerate contents on other servers) - how can I get the enumeration to work? Feedback is FB22955130

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.)

Are there new file-system APIs in macOS 27 that improve performance when writing frequent real-time monitoring logs?

We are deploying Mac mini nodes in a headless server environment. FileVault is required for security compliance, but the boot-time unlock requires physical user interaction, which is incompatible with unattended server deployments. We understand that FileVault by design requires an external actor to provide the unlock secret. What is the supported mechanism for an external trusted service to supply that secret automatically at boot — similar to BitLocker + TPM + network unlock on Windows — without requiring physical access to the machine?

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?