smb big sur

[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

[quote='828338022, abhishek12, /thread/775601?answerId=828338022#828338022, /profile/abhishek12'] In this application, we wanted to have user experience, where user can double click on app icon and launch it. And then application will do its work and close. [/quote] There’s no good way to do this because, fundamentally, it’s not a standard Mac user experience. Whatever you do is gonna be weird. Even if the code is 100% fine, the user experience will not fit in with the rest of the platform. A better option would be for your app to have a minimal UI. This isn’t a big ask. It’d just display a standard menu bar and a window, allowing the user to understand that it’s running, quit the app, and so on. [quote='828338022, abhishek12, /thread/775601?answerId=828338022#828338022, /profile/abhishek12'] we may also need to listen to some events etc on event loop) [/quote] What sort of events are we talking about here? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eski

[quote='775908021, southbayjt, /thread/775908, /profile/southbayjt'] Does Network framework have a built-in way to stream those bytes straight from disk as it sends them? [/quote] No. When dealing with a large file like this, you have to adopt a streaming approach. That is: Read a chunk of the file off the disk. Send it to connection. When the send completion handler is called, check whether there’s more data to send. If so, repeat the process from step 1. It’s weird that you’re JSON encoding the data. If you’re dealing with large files, JSON is needlessly inefficient. That doesn’t change the calculus above — you could make the transfer smaller by skipping the encoding but there can always be a file that’s too big — but it does affect your on-the-wire efficiency. You’re transferring one third more bytes than you need to. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com