smb big sur

That leads me to Part 2... I did a small sample project which demonstrates that using clonefile on a folder works correctly and is 10× faster than using FileManager’s copyItem method. As I've learned over and over again, you need to VERY careful and thoughtful when testing anything file system related, as it's very easy to build tests that don't actually show what you think. Case in point, I actually downloaded your sample project and did a bit of testing and here are the initial numbers I got: doClone (0.284348 seconds) doClone (0.149546 seconds) doDuplicate (0.340530 seconds) doDuplicate (0.102446 seconds) My immediate thought was that those numbers look REALLY big and the inconsistence is odd. The whole point of file cloning is to be fast and, just as important, all of this is basically manipulating the file system structures in memory so the time required shouldn't vary much. SO, the first thing I did was modify your project so that it reused the existing source data (if it already existed) inste

Things went long, so you get a Part 1... Is FileManager using cloning behind the scenes? Yes. More specifically, most of our copy APIs are actually built on top of copyfile, and copyfile is what actually handles file cloning. Or more exactly how guaranteed are we it will use it? It basically uses it everywhere it can. That includes both the obvious case of copying within a volume but also includes less obvious cases like copying a hierarchy that includes clone between two APFS volumes. Generally speaking, you should get the same results as what you'd get copying using the Finder*. *The one exception I can think of is copying files within an SMB server which will definitely be slower and which I believe will also bypass cloning. You can read more about that particular issue here. (I know it does, I tried manually cping the resources and it was thousands of times slower.) Just to clarify, I assume you meant manually copying the contents (using open/read/write), not using the cp command? cp also uses co

I don’t think you’ll be able to replicate the Finder’s algorithm with 100% fidelity. Finder shows the user a view of the system that’s is far removed from the on-disk reality. In some cases those differences are obvious — for example, Finder unifies /Applications and /System/Applications, it treats packages as a single item, and don’t get me started on the Trash (-: — but there are lots of more subtle variations. You can use AppleScript to interact with Finder’s view of the file system. For example: tell application Finder set finderCount to (count of items of folder Applications of startup disk) end tell set actualCount to (do shell script ls /Applications | wc -l) as number {finderCount, actualCount} On my Mac this returns {126, 84} because finderCount includes the apps in /System/Applications. Getting this to work for a big folder hierarchy is likely to be tricky. One nice feature is the entire contents property: tell application Finder entire contents of folder Test of home end tell In theory you

We have two big components: Apple AI and CHATGPT We can post openly about the latest ChatGBT but not it's integregration with 18.5 IOS. I've noticed that ChatGBT needs to be more tailored and taught by my past works. Ideally I'd like to take my works (emails, books, etc) and feed it to ChatGBT to get a more me version of the text. Yet what forum is there to do this ?

Note: The message below is structured in the order I wrote it, but the later section on the VM system is probably what's most important. The short summary is that I think something you're doing is pushing the VM system past where it should be operating. The watchdog panic just happened to be how that underlying problem presented. It is a bunch of files of varying sizes. Here's a Yeah, that's only 60gb for free space, so you shouldn't be that tight. Is your file system the source or the target for the zip file? It's actually both. Interesting. A few questions on that point then: Does the panic happen when you're just the source and/or destination or only when your both? I suspect it will happen when you're just the destination and won't happen when you''re just the source, but I'd like to confirm that. How fast is the I/O path back to the server? Are you saturating that connection? Is the I/O pipeline here simply read compressed file from network-> decompress data-> write data out to network? Or is there

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.