smb big sur

Wow, Kevin. That's excellent support, thank you so much for making the effort! I had no idea that using concurrency in file system calls would have any such effect. You proved me wrong. In a real implementation, I think you'd probably want a fixed set of threads calling getattrlistbulk, another set of threads processing the data each call produced, and then system the pushed directory back to the syscall thread. Already doing all the processing past the initial gathering of the directory contents in a separate thread, but that's clearly far from what's possible. I actually tracked this bug down and I have a question about your testing. Were you always testing on freshly mounted volumes (meaning, umount volume-> mount volume-> searchfs)? Or did you also test on volumes under normal use and repeatedly running searchfs? The use case of my app is to mainly run searches on the entire startup volume. So that's what I focused on with my tests. I try to be aware of caching effects (I believe some OS versions ca

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. No, it doesn't work that way. More specifically, there are basically two levels where caching can occur: At the system level, where all processes have a coherent view of what they believe the file systems current state is. At the process level, where processes have whatever data they last received from #1. The key issue here is that the system level cache IS the VFS layer. The POSIX APIs operate as the bridge between those two layers and that means they minimize any kind of caching (since that would only complicate the bridge). That is, the ony level above the VFS layer IS NSURL. It should be caching the data it's getting from getattrlistbulk (that's one of it's jobs) and it shouldn't be seeing the large performanc

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, my first and biggest warning here is that this kind of performance testing is excruciatingly tricky and error prone. There are so many details and edge cases that distort the results, all of which make it very hard to be entirely confident in any conclusion. The next thing to understand here is that the fundamental performance issues and the corresponding solutions are EXACTLY the same across basically all of the APIs your looking at. More specifically, going back to your article here: https://blog.tempel.org/2019/04/dir-read-performance.html ...you reference basically 3 APIs. Here are the APIs and their underlying implementation: contentsOfDirectoryAtURL-> Implemented as a wrapper around enumeratorAtURL, which is wrapper around getattrlistbulk. opendir()/readdir_r()-> Wrapper aro

[quote='829701022, mungbeans, /thread/776743?answerId=829701022#829701022, /profile/mungbeans'] How should a framework be statically linked into its parent framework, which setting in Xcode controls this? [/quote] There are three basic strategies for this: Build a static library. Build a static framework. Build a mergeable framework and then choose to statically link it. Honestly, I’m a big fan of the last option because it gives your clients the most flexibility. Regardless, the exact process depend on a variety of factors, including the build system you use to create the library and the build system you use to consume it. For Xcode, there are various articles in Xcode > Bundles and frameworks and Xcode > Build system. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='776929021, neil218, /thread/776929, /profile/neil218'] Is there a way to enforce strong password requirements when using the .applicationPassword flag? [/quote] There is not. I think that’d made a fine enhancement request. If you do file an ER, please post your bug number, just for the record. [quote='776929021, neil218, /thread/776929, /profile/neil218'] If enforcing strong passwords isn’t possible, is there an alternative approach to provide a predefined strong password during the creation process, bypassing the need for user input? [/quote] No. But I suspect I’m missing something here. Let’s say you could do this, what would the workflow look like? Would you expect the user to remember this high-complexity password? That seems rather… well… brittle. [quote='776929021, neil218, /thread/776929, /profile/neil218'] With SecAccessControlCreateWithFlags, I noticed the item isn’t stored in the traditional file-based Keychain but in an iOS-style Keychain … ? [/quote] Correct. This is officially known as th

What is the maximum of CPU power that an application can consume? So, the first thing to understand is that the percentage here is both relative to each device and somewhat made up. The evolution here started with single core machine where, in theory, it meant the CPU is completely busy. When symmetric multi-core machine came along, the decision was made to treat each CPU as it's own percentage, so the max percentage of a (symmetric) 2 core machine was 200%. Now, when you get to a asymmetric system... that math doesn't really work, a 100% of an E core is lot less computational power than the same percentage of a P core. More to the point, all of these percentage are a bit of an invented abstraction as they don't actually correspond to any kind of absolute measure. Are there any limits and There's a limit in the sense that we decided what percentages we'd use on every machine we ship. could they be modified? I'm not sure what you mean here. They'll absolutely vary between machine models. That is: Across core c

Ironically, the answer is found in a 10 year old post by myself As an additional irony, I'd just finished writing all this up when I saw your own post. Filling in some details which may be helpful... (This was a bit surprising to me - I'd have thought that Windows or SMB would hide the fact that the share has sub-volumes, and simply show them as directories - and that's what it did in older macOS versions indeed, e.g. in High Sierra. But in Sequoia, these sub-volumes on the Windows side are mirrored on the Mac side, and they behave accordingly) This is actually done by something called DFS (Distributed File System), which is actually designed to allow an organization to present a unified hierarchy across multiple servers as well as shares. The broader protocol obviously handles much more that this specific volume case and I suspect they used it here because it handles standard edge cases better* and the work had already been done. *For example, exposing the secondary volume as a separate share means

First off, as some clarifying background context, there has always been a pretty large gap between how the HID specification was intended to work and what actually ships as hardware. In theory, HID devices should be largely self documenting. The accessory describes it's physical configuration, the system maps that configuration into the system user interface, and everything just works. Unfortunately, in practice that's not how most hardware actually ships. More specifically: HID has been fairly widely used as software control/configuration API, not just for actual control accessories. For example, MANY microphones have one or more secondary interfaces which are used to configure the microphone. HID actually works VERY well for this sort of thing, though it does mean that an app needs to be careful about how it interacts with whatever it finds. A very large percentage of HID accessories present HID configuration which are WILDLY out of line with their physical configuration. It's entirely possible that hardwar