smb big sur

Thank you for such a detailed answer! Is there any sense in creating an enhancement request for a daemon-safe API (one that can be safely used within a daemon)? I think most of them are daemon safe. NSURL is daemon safe (it's part of Foundation, which is documented as daemon safe), as are the BSD APIs below it. Expanding on what I said here: ...I expect diskutil to work fine in a daemon context as long as you avoid commands which trigger UI. This is mostly an issue of looking at the man page and avoiding obvious edge cases. For example, diskutil commands to unlock volumes can present UI and/or access the keychain, which won't work in daemon. So don't do that and it will work fine. I've been somewhat vague because diskutil is a big command with lots of edge cases and you should test all the details for yourself, however, in practice I don't expect you have any problems. Shifting to the enhancement request question itself... Is there any sense in creating an enhancement request for a daemon-safe API (o

Yeah, same here! I’m seeing that issue with Sky Gamblers too after Big Sur.

Some factoids: I can’t help you with third-party tools. I’m a big fan of ssmith_c’s answer here. If you have a problem with a third-party developer tool like this, it’s critical that you get things working with Xcode first. If you’re able to use Xcode to create a trivial app from one of the built-in templates and then run it on your device, you know that the Apple side of this is all good, and that allows you to focus on the third-party tool. OTOH, if you can’t get Xcode to work then we can totally help you with that here. It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Best of luck! Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

FYI, you also asked about APFS on this thread and I've moved you answer to that question on this thread. Is it bug or ATTR_VOL_SPACEUSED is unsupported on macOS 11? I don't know exactly why it was done, but I believe it was an intentional choice while the team was sorting out how APFS should present itself to the VFS system. ATTR_VOL_SPACEUSED is actually calculated in the VFS layer (you can see the code here if you're curious) and I suspect that at the time vs.f_bused wasn't giving a value that matched well with the expectation of the rest of the system. Disabling ATTR_VOL_SPACEUSED was the easiest way to prevent that from causing broader problems. That leads to here: Are there any other way to get space which is used on an APFS volume? (C++) So, the basic answer is what's the described in Checking Volume Storage Capacity. The more complicated answer starts with What are you actually trying to do?. The big issue here isn't simply that APFS is more complicated (which it definitely is), it's that part

[quote='783226021, billh04, /thread/783226, /profile/billh04'] How can you force cancel a task that … doesn't check for cancellation? [/quote] You can’t. [quote='783226021, billh04, /thread/783226, /profile/billh04'] would this be a useful addition to Swift? [/quote] Unlikely. You’re reasoning from a false premise here. All meaningful Swift functions require some sort of cleanup. The fact that this cleanup isn’t obvious is just the compiler hiding fiddly implementation details from you. A classic example of this is ARC, where you don’t have to worry about cleaning up because the compiler is emitting all the necessary retains and releases. Given that reality, there’s no way to stop code that doesn’t check for cancellation. Attempting to do that would leave the program in an undefined state. For example, a valid implementation of malloc would be: Lock a mutex that protects the memory allocator’s state. Manipulate that state to allocate the memory. Unlock the mutex. Return that pointer from step 2. If your task

If you haven’t already found it, please read An Apple Library Primer. But before we start talking about the dynamic linker, I want to chat about the big picture. You wrote: [quote='783167021, mettar, /thread/783167, /profile/mettar'] I have offered to help port a custom debug tool that revives a process from a core file. [/quote] What sort of fidelity are you looking for here? This is impractical in the general case because macOS leans heavily into Mach IPC. The vast bulk of system services aren’t provided by the kernel but are instead provided by daemons and agents via IPC. A process typically interacts with those via Mach IPC, and specifically XPC, and rebuilding those connections is pretty much impossible. So, if your OK with limiting this to Unix-y APIs then it might be worth continuing down this path. But if you want to get this working for apps, you should rethink your life choices )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + app

It's going to be a big challenge to port an existing project to SwiftUI. What you describe makes a lot of sense. Most people never encounter this error anymore because they are starting small, with a new project. That being said, you specifically said that you were porting a project over to iPhone. I don't think trying to do that kind of massive port from a foreign architecture is going to be any more pleasant in UIKit. I recommend starting small, with a new project. Build the bones of your UI to match the old project. But don't attempt to port the entire thing at once. Follow the path of least resistance and write the code the way SwiftUI or UIKit expects.

I think you're looking for something like this: import SwiftUI struct ContentView: View { var body: some View { ScrollView { VStack(spacing: 24) { ForEach(1..<20) { i in Text(Line (i)) } } } .frame(maxWidth: .infinity, maxHeight: .infinity) .background( Image(background) .resizable() .scaledToFill() .ignoresSafeArea() ) } } #Preview { ContentView() } The main difference is that my code adds a background to the ScrollView rather than putting everything on top of an image via a ZStack. When you do it your way, you've kind of told everything on top of that layer how big they'll be, which is why your ScrollView is distorted, and bits of it disappear off the screen.

These are the Developer Forums, where developers of apps for Apple's platforms ask each other for hints and tips on coding. Your question is more of a product support one, so I'd suggest you ask it over at the Apple Support Forums. Thanks. System data is the System, i.e. iOS plus necessary files such as logs and cache files. That number will stay pretty static. There's not really a lot you can do to reduce that. Try and offload some of your data to iCloud. Enable iCloud Photos and turn on Optimise iPhone Storage in Settings > Apps > Photos. Regardless, you have a 64GB iPhone, which isn't that big these days. It might've been fine five years ago, but not really now.