@ben_roeder I don't think that is the same issue as what was originally described, and I'm not Apple, but I have seen something similar, although I reproduced it after rebuilding the app with Xcode (FB22516139). Maybe this is what you're hitting. I checked the status on my feedback about that and it says a fix is coming in a future OS update, although I'm not sure specifically which beta version, if any, currently has the fix.

[quote='885813022, DTS Engineer, /thread/824156?answerId=885813022#885813022'] Some of the information here may already be obvious or well understood to you. [/quote] Thank you for taking the time to write all this down. That context is very helpful, especially as I'm not super familiar with the lower level Unix APIs related to this. [quote='885809022, DTS Engineer, /thread/824156?answerId=885809022#885809022'] I don't think that's a safe assumption and, in practice, I think you're very likely to see lots of cases where a lookup ISN'T generated. I don't think a basic "ls" will generate a lookup call and I'd expect/hope the Finder would avoid it at least some of the time. [/quote] Both of those expectations don't The second expectation doesn't seem to be what happens in reality, at least on macOS 15.7.5. I've been testing with a sample file system that has a directory with 10,000 items. When I do a time ls /Volumes/MyFS/dir, I see that a lookupItem call was done for every single item (actually, 2 for each item, e.g. one for file1.txt and another for ._file1.txt, which doesn't exist). And if I open /Volumes/MyFS in the Finder, then it immediately goes wild at making lookupItem calls to the thousands of items in the /Volumes/MyFS/dir before I even open dir (although, I do have the "calculate all sizes" view option enabled in the Finder; when I turn that off, it at least waits until I open dir). Edit: OK, actually, it seems like my shell has added extra stuff to a "default" ls call... it's probably oh-my-zsh or something. When I run it in a plain bash shell, a regular ls doesn't make all those lookup calls. But it also doesn't ask for any of the heavy attributes that lead to my codepath that can instantiate the FSItem object, so that specific case doesn't lead to a leak in my code. These operations (the ls and opening the big folder in the Finder) are really slow, and while a lot of it seems to simply be FSKit overhead (FB21069313), I'm currently trying to optimize my own code to avoid some of the bottleneck on my side. I guess, writing this down, it really looks like the "FSKit overhead" might be the tons of lookupItem calls... so if that's not intended behavior, then yeah, sounds like my assumption wouldn't work and I should be trying to figure out when to prune these objects. [quote='885809022, DTS Engineer, /thread/824156?answerId=885809022#885809022'] That bottleneck either provides the cached object it already has or creates a new object (adding it to the cache) if it doesn't have one, ensuring that there is never more than one object for any given file system object. [/quote] Yeah, I've currently got something like that. I'm currently relying on reclaimItem calls to know when to release my hold on the object from the bottleneck, but I was recently reading my code again and realized that I might be never reclaiming it if the system never actually receives the item! Hence I came to the forums to ask this, to see if this is actually a problem or not. [quote='885809022, DTS Engineer, /thread/824156?answerId=885809022#885809022'] First off, as background context, I have a post on this here which is worth reading. [/quote] Oh hey, that's an answer to one of my previous questions :) [quote='885809022, DTS Engineer, /thread/824156?answerId=885809022#885809022'] As a block storage file system, one thing you should be looking at/planning is to transition to FSVolumeKernelOffloadedIOOperations and away from FSVolumeReadWriteOperations. [/quote] Got it. I do have that implemented, although right now I'm rejecting any request that contains the write flag. I also don't have any of the supporting write functionality (creating files, changing attributes, etc.) done, which is probably going to be the hard part with that.

[quote='885683022, DTS Engineer, /thread/824156?answerId=885683022#885683022'] my expectation would be that iterating the directory with "geattrlistbulk" and a minimal attribute set would avoid any additional lookupItem call [/quote] Oh, I think I was a little unclear in what I wrote. What I was trying to say in "a call to enumerateDirectory of this nature" was that if I call enumerateDirectory with a non-minimal attribute set (i.e. include attributes that need more I/O to fetch) then I see that behavior. But you're right in that iterating over a directory with minimal attributes doesn't generally have additional lookupItem calls in my tests. [quote='885683022, DTS Engineer, /thread/824156?answerId=885683022#885683022'] What kind of filesystem are you working with? [/quote] It's a block device file system. I think maybe "cached data" wasn't the best word for me to use... I'm referring to references I'm keeping to instances of my subclass of FSItem. I have a helper function implemented on my subclass to get the "non-minimal" attributes, so what I'm doing in my enumerateDirectory implementation is checking if I have a reference for the item already, and if so, I simply use that and its helper method. If not, I create a new instance of the FSItem, then proceed. (If there are only minimal attributes that don't need any more I/O requested, then I don't do anything with these FSItems.) My question is more so, if I'm creating a new FSItem in enumerateDirectory like that (for the purpose of getting those "non-minimal" attributes), can I assume a lookupItem call is going to follow, and thus giving the system a chance to later reclaim that FSItem? Or should I be throwing away my reference to the FSItem if I created it inside enumerateDirectory? It seems like it would be a bit wasteful if I threw away an FSItem made in the enumerateDirectory call if I know there's going to be a lookupItem call shortly after asking for it, although I don't see a guarantee that that would be the case. [quote='885683022, DTS Engineer, /thread/824156?answerId=885683022#885683022'] That's particularly true on macOS where your I/O is page oriented, so the minimum cache unit is 16Kb (one page). [/quote] Oh? Does this mean it's not good to pass lengths smaller than 16KB to e.g. metadataRead, and what its docs are referring to when they say "This method doesn’t support partial reading of metadata?" It's often the case that I've been using 4KB, and things seem to run fine, although right now I only have reading implemented, so I don't know if that causes a problem later if I implement write.

Thanks, Quinn and Kevin! I was going to see if I can do a full test of this before I make a release with requestedMountOptions included, but it looks like the availability version has been updated, so I think it's going to be a moot point by the time macOS 26.5 releases. In any case, interesting read as always.

You might also want to try reporting this at https://security.apple.com/reports, which has an option to report malware/phishing. I've never reported malicious App Store/TestFlight builds there, but in my experience filing other types of security bugs there, you often get more info about what is happening to your report and/or a better chance of a response than you do with Feedback Assistant.

Hmm. I tried something like the code you sent, and same as you, it compiled. But when I changed iOS to macOS in the availability macro (which I assume is what you intended to write), then I get the compile error... weird... this is also the case if I change FSVolume.MountOptions to something like Int, so it's not because the FSKit types are macOS only. Here's some sample code that reproduces this (also added the code to my feedback): @objc protocol SwiftProtocol { @available(macOS 26.0, *) @objc optional var requestedFoo: Int { get set } } class ReproduceBug: SwiftProtocol { @available(macOS 26.2, *) var requestedFoo: Int { get { 0 } set {} } }

[quote='884798022, DTS Engineer, /thread/807771?answerId=884798022#884798022'] I don't think you actually need to use an availability macro at all. [/quote] In this case there's a compile error if I don't include the macro as my minimum deployment target is macOS 15.6 and FSVolume.MountOptions is not an available type in that version. [quote='884798022, DTS Engineer, /thread/807771?answerId=884798022#884798022'] Not sure why that's happening, as "requestedMountOptions" should be optional, so you don't need to implement it all. [/quote] Yeah, it was quite weird... I actually had a drafted FB about that compile error that I haven't cleaned up and submitted yet. I found some time to do that (FB22525990), though as long as putting 26.0 in the macro doesn't cause any weird or undefined behavior then it shouldn't be that big of a problem. Thanks for helping out with this!

FB22267894 is fixed in macOS 26.5 beta 2. Now code like @available(macOS 26.0, *) var requestedMountOptions: FSVolume.MountOptions { get { return [.readOnly] } set {} } has the desired effect. Also, as a follow-up question, is @available(macOS 26.0, *) safe in this case? I saw in the macOS 26.4 release notes that the availability version is wrong and actually 26.4, not 26.0 (171914656). However using @available(macOS 26.4, *) fails to compile [1], which seems kind of odd. Will that cause problems in macOS 26.0 through 26.3? [1] with the error Protocol 'Operations' requires 'requestedMountOptions' to be available in application extensions for macOS 26.0 and newer

Via a reply to FB22286320 last Friday I was told to verify it is fixed in macOS 26.4 (25E246). Not sure if they meant to make the VM on a 26.4 host or using the 26.4 restore image, but the latter still doesn't work on a Sequoia host without manually installing the mobile device support package (they still don't auto-download from the software update server). If they meant the former, well, I don't think that was under dispute ;) although given that 26.4 is released by now I suppose it really is only affecting Sequoia hosts at this point.

I'm still seeing this on the release version of macOS 26.4 (25E246). I looked at this a little more, and I don't think requestedMountOptions is actually being read. I changed my test implementation to do something like this: var requestedMountOptions: FSVolume.MountOptions { get { Logger(subsystem: "com.kpchew.FSKitSampleApp", category: "default").log("Reading requestedMountOptions") return [.readOnly] } set {} } and I never see the log message. Edit: also I'd like to add that the documentation says requestedMountOptions should be read after the extension replies to mount. However I don't actually see either mount nor unmount get called either (FB22343796), so maybe that's related?

In zsh a highlighted % means there's no newline at the end of the output. It's not literally a % in the output and shouldn't affect anything if you're using the output programmatically. e.g. if you direct its output to a file you won't see a %

During the beta cycle, developers can get the required MobileDevice by installing the latest Xcode seed. That's problematic on macOS 15.x because Xcode 26.4 now requires macOS 26.2. However, would it be possible to open the Xcode.app/Contents/Resources/Packages/MobileDevice.pkg manually on a macOS 15.x machine to get the required mobile device files? Once the OS is released, either: That doesn't seem to match my experience. macOS 26.4 is now out, and I've updated to macOS 15.7.5 (24G624), but when I try using the restore image of the release version of macOS 26.4 to make a VM, I'm still prompted to install the mobile device files and it still says that they aren't available from the software update server.

maybe it would work to make a VM with an earlier macOS version then update it? Regarding this idea, my storage issues cleared up with the final release of macOS 26.4 (the new update required about ~5 GB of VM in my pre-existing VM, but the RC wanted about ~35 GB for some reason). I was able to update the VM and run it. So, it does seem like a possible workaround is to install a VM with an older version of macOS and then use Software Update inside the VM to update it to 26.4.

On my macOS 15.7.4 machine: $ pkgutil --pkg-info-plist com.apple.pkg.MobileDevice <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>groups</key> <array> <string>com.apple.findsystemfiles</string> </array> <key>install-location</key> <string>Library/Apple/</string> <key>install-time</key> <integer>1771452321</integer> <key>pkg-version</key> <string>4.0.0.0.1.1762585687</string> <key>pkgid</key> <string>com.apple.pkg.MobileDevice</string> <key>receipt-plist-version</key> <real>1</real> <key>volume</key> <string>/</string> </dict> </plist>

AFAIK there’s no magic here. And I tried reproducing this on my main work Mac and didn’t have a problem. @DTS Engineer When I have this issue, it also comes with a prompt that appears offering to download the device support files, but this fails because the files aren't available from the software update server. Given that you're an Apple employee, is it possible that your work Mac has access to an internal software update server that offers the required device support files, but that the public software update server doesn't?