File Systems Q&A

There has been a lot of speculation/explanations offered over the years about why this functionality was removed from Disk Utility, but some of it is contradictory. I'd love to hear a definitive answer from the experts – what's the technical reason that Secure Erase is not offered for SSDs?

Enlarging the working set is straightforward — every item returned from enumerateItems(for:startingAt:) becomes part of it. But how do we safely remove items? If we exclude a folder from working-set change enumeration, the system shows the user an obsolete version of that folder, because it never calls enumerateItems(for:startingAt:) for it again. (Note: It seems system does call enumerateItems(for:startingAt:) again for materialized folders after extension restart.) What's the intended way to evict items from the working set?

On a folder's first visit, the system materializes it via enumerateItems(for:startingAt:). Subsequent visits don't re-enumerate; freshness seems to rely on enumerateChanges(for:from:) on the working set. However, after an extension restart, visiting an already-materialized folder triggers enumerateItems(for:startingAt:) again — even though working-set changes were already consumed. So is enumerateChanges(for:from:) not the sole channel for keeping materialized items fresh? Under what conditions does the system re-enumerate a materialized folder?

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

What does volumeSupportsPersistentIDsKey represent and guarantee on macOS? Is it specifically about persistent filesystem object IDs such as fileIdentifierKey / inode / systemFileNumber, or can it refer to other kinds of persistent IDs? For which common volume/filesystem cases would this property be false, and what should I fall back to as file identity in those cases? Thanks!

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

In an NSFileProviderReplicatedExtension, is enumerateChanges(for:from:) ever called for enumerators other than .workingSet, or is it exclusively used for the working set?

Is this functionality on the horizon or available in macOS 27? In lieu of snapshot reversioning, this would go a long way towards improving performance and logistics of restoring from a snapshot. For example, if I create a snapshot on a 2TB volume containing 1.5TB of data, then delete all of the files on that volume, it's logistically infeasible to restore that data back to the same volume without either snapshot reversioning or using clonefile() to recreate the file references on the live volume.