Kevin, I appreciate your involvement in this, and your willingness to dive deeper into this for my (and hopefully others') education Some of the things you explain about performance were already clear to me (I used to write file systems and a simple operating system in the long past). Some were not clear, e.g. I have assumed that maybe some of the NS based calls were happening in a kernel space where making calls to the lower APIs would be less wasteful, or that NSURLs, which these calls return would be pooled at a more efficient level (where I only recently learned from Jim L that it was for me using NSString for paths where the fileSystemRep was the key to keeping it faster). I also agree that some of the properties, such as "NSURLIsVolumeKey" shouldn't be costly because they should not require another call into the BSD/POSIX APIs as I'd have thought that the information is already present at the level above the VFS. And that's especially true for the NSURLIsDirectoryKey. Architecturally, the performance here should basically be "identical", as the ONLY reason "hasDirectoryPath" can work at all is that the enumeratorAtURL "told" the URL it was a directory at the point it was created Exactly my thought - I concluded that from logic, without looking at the source code. You're aware that NSURLs append a "/" suffix to dirs, while paths do not, right? So, I suspect that hasDirectoryPath simply checks for that trailing "/", hence it being so fast. BTW: If you time the "find" tool, you'll see that it can be almost twice as fast as my DirScanner tests. Which surprised me. I still wonder if NSStrings conversions play a role in that, which the find tool doesn't have to worry about. [quote='830058022, DTS Engineer, /thread/776198?answerId=830058022#830058022']the only explanation I have is that there's a serious issue in our current implementation and the resource cache simply isn't working properly. Please file a bug on this and send me the bug number once it's filed.[/quote] Huh, well, okay. I was already expecting that anyway, but never bothered to report it as a problem because I didn't think anyone would bother with it. I had reported, for instance, an issue with searchfs(), which has become much much slower in APFS over HFS+ (like, 6 times slower for the same amount of files, when it's an entire startup volume), and this was not addressed, as far as I can see. And if we're talking about performance issues on the FS, the worst offender is Finder and its support frameworks. I have once run a trace of calls (e.g. with fs_usage) and I found that there's a LOT of repeat calls for the same attributes, which explains why nowadays browsing the Applications folder, especially over a network volume, is so awfully slow (it's mainly about diving into the bundles). THAT needs addressing, and it's so obviously bad - it should be obvious to anyone using a Mac for a few hours, especially if they have some experience how fast it should be (and indeed used to be!). As long as that isn't tackled, I wonder why I should make an effort to report these rather minor bottlenecks. But then again, maybe, if enumeratorAtURL is used by Finder a lot (can't dtrace anymore, can we?) and and this gets improved, maybe it'll automagically also improve browsing in Finder all over, significantly? If you think so, I'm happy to make the effort. (Feel free to email me directly if you have private comments, I don't want to start a flame war here, but rather really care about this getting better, if I can make a difference. Incidentally, I had applied for a job a few times working on FS improvement in the past but nothing come of it.) [quote='830058022, DTS Engineer, /thread/776198?answerId=830058022#830058022'] my advice would probably be to build and optimize entirely on getattrlistbulk. [/quote] Yes, that's indeed on my wish list, after seeing how the find tool can be so much faster (my app has now a mode where it calls the find tool and then my app just looks up the paths it reports back, and that's twice as fast). But then, I also want to improve the UI a lot and add a caching of the FS by tracking all changes and keeping a shadow directory, and that'll benefit my users more in the long run). Only so much a single programmer can accomplish :) using multiple threads and making multiple calls into getattrlistbulk simultaneously Yes, that's on my list as well, and yes, especially for network vols. Also, I had already planned this before SSDs became common, and I'd thought to identify which drives where on the same HDD, and only run concurrent searches on separate HDDs, to avoid excessive seeking. Though, I still have to experiment with this, because I'm not sure if the VFS would queue calls on a global level - but in recent years I got hints that this would not be the case, and I'd be able to have multiple FS calls run concurrently if they're on independent file systems, and you seem to indicate the same. Which is promising. However, most users of my app are simple "home" users who only search on their startup disk, and there's little to parallellize there. I had, for instance, considered to pre-cache the locked system volume, but then, the time for searching that volume is fairly quick compared to the /System/Volumes/Data volume, so caching the former doesn't gain much in the overall search time once the user has accumulated lots of files (which happens eventually). Again, thank you for not only trying to answer my questions but also exploring solutions.

Kevin, I'm using both a simple recursive iteration (contentsOfDirectoryAtURL) and enumeratorAtURL. In both cases, before I read the dir contents, I check if it's a volume with a trigger flag - if it is, I call opendir, readdir, closedir before I invoke one of the above FSFileManager methods again. That way, at least in my use case, the sub vols get mounted right away by the opendir/readdir, and the next filemanager call provides me with the new volume's contents. I only have one user out of 10000s who has reported this issue so far, for the >15 years I have my app in the public, so I consider this a "quick'n dirty" fix that works well enough for now. I've noted down your comments, though, in case I have to work on this again. I have a concern about performance, though: I like to be as fast as possible with the iteration, especially if I only need to look at file names. So, when calling enumeratorAtURL, I fetch no extra URL properties, and detect directories by called url.hasDirectoryPath, which turns out to be faster than checking NSURLIsDirectoryKe. If it's a dir, then I call getattrlist to get the mountpoint values. (See my "DirScanner" test project at https://files.tempel.org/Various/DirScanner.zip, which also employs this technique to avoid diving into other volumes, e.g. when browsing from "/" down.) Any idea if there's a better way? (I also learned recently from Jim Luther that it's much faster to use the C-string "url.fileSystemRepresentation" path instead of first getting url.path and then getting its UTF8String because that skips come costly internal conversions. Same for creating URLs when the name/path comes from POSIX/BSD functions. I've updated my DirScanner code accordingly.)

Ironically, the answer is found in a 10 year old post by myself (https://stackoverflow.com/a/28663838/43615). Basically: Before diving into the dir, get the ATTR_DIR_MOUNTSTATUS attribute and check the DIR_MNTSTATUS_TRIGGER flag. If it's set, it means the dir is currently not mounted but will trigger a mount once it gets read. So, if the flag is set, I only have to read the dir's contents (which will report back as being empty), and then I can immediately read again, and this time the mount will be there. I thought that there would be a delay, but apparently this happens synchronously. Alternatively, if I do not want to check the flag beforehand, I could also, if I find an empty dir, check if the dir is a mountpoint (DIR_MNTSTATUS_MNTPOINT flag) and if it is, re-read the dir.

I am in the same boat and am now confused - I thought the solution, for ObjC, was to use SKReceiptRefreshRequest to refresh the receipt?! My personal problem, though, is that I cannot test my code now. I seem to need a fresh system that has never seen the app before. I tried to create a VM with Fusion 11.5.3 as well as 13.5.2, but in all cases, I was only able to install macOS 10.14 or 11, but then upgrading to macOS 13 or 14 always results in kernel panics during install or shortly thereafter, with all settings still being defaults (other than increasing CPU cores and memory). Of course, this needs to be done on an Intel CPU Mac, because the Silicon Macs don't support the App Store in VMs. This is so fooked up.

Done: FB15568200

Aaand I've confirmed it: After restoring the VM to 15.1beta where FAF hasn't been launched under yet, then deleting all copies of FAF (which are easy to locate with my "Launch Services" app) and then installing the single new version that contains the new key, I finally see the new usage description. So my suspicion was probably correct: When prompting the user about the Local Network permission, it doesn't fetch the NSAllowsLocalNetworking value from the running app but from Launch Services, and in a way that doesn't ensure it's looking for the data from the latest or running version of the app, which it should. Which isn't really a new issue when I think about it - I believe I've noticed more than once in recent years where Finder or other services failed to register new information from the latest version of an app but instead use data from outdated versions that are still installed elsewhere. I wonder if this is even worth a bug report. It might be behaving "as designed".

Nevermind - I found a test project myself (my own SSDP Browser on github). There, indeed, setting the NSLocalNetworkUsageDescription does work. After verifying that, I checked my main app FindAnyFile again. Lo and behold! After changing the app's bundle ID, it suddenly worked! Now, the issue here seems to be: The app was already known to macOS BEFORE upgrading to Sequoia. When running it on the updated Sequoia for the first time, the prompt for Local Network appears, but it's showing the default and not my custom usage message. However, if I install and run the app for the first time on Sequoia (which I simulate by giving it a new bundle ID), it does show the custom message. So, I still believe that there's a bug in macOS 15.1, by which is doesn't show the app's NSLocalNetworkUsageDescription if it has been installed before, or possibly if there are also OLDER versions of the app around that do not contain the NSLocalNetworkUsageDescription, meaning that this information is cached somewhere else by macOS and is not updated with the LATEST app's information. Can you tell me where macOS gets the NSLocalNetworkUsageDescription text from? Apparently, it's not reading it directly from the running app's Info.plist but from somewhere else, e.g. the LS database? If it's that, I could dump that to check why it doesn't get updated - or maybe it's updated there but the macOS code looks for the first app instance in the LS database instead of looking for the latest. Something is clearly wrong there and I'd like to help figuring out what, so that I can provide a clear and reproducible bug report.

Actually, the cause might be that, since I'm using a NSSearchToolbarItem on macOS 11 and later, I need to invoke its beginSearchInteraction method instead of making its searchItem the first responder. While doing the latter used to work, this has apparently become unreliable in macOS 15. It's weird that it sometimes still works, though, making this tricky to notice and debug.

Thank you for double checking that it should work on macOS. yes, I showed the plist of the app that I had launched. Not localizing the text. App is signed with dev id and notarized. Do I need special entitlements for this to work? App is not sandboxed if that matters. Can you share the app that you verified to work so that I can compare?

Well, that's just the thing: That text is not displayed in my tests. Instead, it shows a generic msg. In both 15.0.1 and latest 15.1beta. Here's the prompt that appears and the Info.plist of that very app:

BTW, there's another issue with the new Local Network permission: There's no way to provide a "UsageDescription" for it, like for all the other ones, in Info.plist. (At least, Xcode 16.1b3 doesn't list any under the "Privacy - …" keys)

Adding to my last "Later" comment: No, sometimes, even new versions with the same Signing ID get added as unique entries. I can't make sense of when this happens and when not, but here's the result: And all 3 "Find Any File" items point to the same file and not, as expected, to the different versions that are all on the disk, at different paths.

Bundle ID and designated requirement are all the same. Path is not, as mentioned above. UUID is also different, as they're different builds. But that just confirms what I suspected: That the privacy permissions are separate for different versions of the same app. However, my concern was that even if that's done on purpose, then System Settings.app / Privacy / Local Network shouldn't show the SAME app version multiple times but should list separate apps, i.e. the different versions it has recorded so far. To illustrate: ... Here I was going to reproduce the issue and show you a screenshot of the Settings app showing multiple instances of the same app, each pointing to the same path. But now that I had re-installed Sequoia and run each app version, they do not multiply in the Local Network list any more as they did before. And the screenshots of this effect that I had done before in the VM are lost when I borked that system. Sigh. Alright, let's drop this for now. I'll get back to this thread should I encounter the problem again. Actually... I just read https://developer.apple.com/forums/thread/737416 which confirms that it's possible that multiple app instances are listed. So you know about this effect. Then let me get back to the issue with that: If you have multiple app instances listed under "Local Network", and if you right-click on them to Reveal them in Finder, you'll get the SAME app revealed each time. This means that the code that lists the multiple instances in the Settings pane does not keep them separate for the sake of indentifying them to the user, which is clearly a bug. Agreed? I'd write a bug report but since I fail to be able to reproduce this, I believe it wouldn't get even any attention. But if you do, could you do something about it, please? Later Ahh - it appears that app versions with the same Signing ID are listed as one instance. Only if the Signing ID is different, e.g. for MAS vs. Indie releases, it's listed multiple times.

To get started, look at the SRVResolver sample code. In case others run into this, let me add this warning about the SRVResolver code: In the function QueryRecordCallback, the code first makes some assertions before checking the errorCode. That's likely to cause problems because if you get an error (such as if a user doesn't give your app permission to use the network calls), the asserts may get triggered. To fix this, move the assert calls inside the code that checks for error == 0.

In case others run into this, let me add this warning about the SRVResolver code: In the function QueryRecordCallback, the code first makes some assertions before checking the errorCode. That's likely to cause problems because if you get an error (such as if a user doesn't give your app permission to use the network calls), the asserts may get triggered. To fix this, move the assert calls inside the code that checks for error == 0.