[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?

I'm also encountering this trying to make a 26.4 RC VM on a macOS 15.7.4 (24G517) host (a M3 MBP) (FB22286320). I have a VM working from a previous 26.4 beta that was originally on an earlier version of 26, but I wasn't able to upgrade it to the RC via Software Update due to storage constraints :( maybe it would work to make a VM with an earlier macOS version then update it? I haven't found time to test whether that works, though.

[quote='880540022, DTS Engineer, /thread/807771?answerId=880540022#880540022'] I think you're seeing #2, but I want to confirm that. [/quote] AFAICT it seems to be #1. There was a small issue in the test project I submitted to FB22267894 [1], but when that is changed, if I set a breakpoint at createItem(named:type:inDirectory:attributes:) (for example) and then touch /Volumes/Sample/hi, I will reach the breakpoint in createItem and see the error that function outputted in Terminal. For example if I change createItem to return EIO, the touch command in Terminal then shows an input/output error. [1] Namely, my lookupItem sample implementation returned ENOSYS for any lookup other than the single static file implemented in the test file system. If it is changed to return ENOENT instead, then I can reach the createItem breakpoint.