smb big sur

No, I never got a response. I filed a DTS, and the engineer who helped me wrote to the CarPlay team, or so he said. They also ignored him. I kept replying to the DTS for a while, until I was also ignored here. I also tried the contacting Developer Support. They replay to my e-mail, assign a case ID, they say they are escalating my request, and they they ignore me. When I replay a few days later, same history. I have also reapplied to get the entitlement every time I have added a big update to my apps which implement navigation. Also ignored. So I made a big investment to add navigation to my apps, I am not granted the entitlement when my use case is similar to other apps which have it, and now I am holding off on some marketing campings, what's the point to try to get more users if this will lead to bad reviews because they cannot see the map in CarPlay. Worst experience ever. I am quite desperate.

If the find a bug in the sample code please file a big report via Feedback Assistant and post the FB number here once you do. https://appleinsider.com/articles/25/04/18/when-you-report-bugs-on-ios-some-content-may-be-used-for-ai-training Thanks… but for privacy reasons I'm currently blocked on submitting bug reports due to a requirement on AI training. Are you referring to the dismiss environment property? I'm referring to the Select and Done buttons that appear to toggle EditMode:

Did I forget something in the InitializeInterrupt implementation? What's actually failing? Are interrupts not firing? Or is something else breaking? Or is there another reason for this issue? My big question here is what the details of this are: Right now, if I first load KEXT, then completely remove it and load DEXT without rebooting the storage, DEXT interrupts work fine. But if I restart the storage, DEXT interrupts stop working. Here is the implementation for initializing MSI-based Interrupts. One thing I would be careful of here is that you're testing scenarios that your hardware will handle in a reasonable way. For example, I've see a few different cases where developers ran into problems when their DEXT was run repeatedly against the same device without hot plugging after the DEXT has crashed. In a lot of cases, this is a pointless case to try and test/fix. If this was a KEXT, the kernel would have panic'd and you'd have reset the hardware. The DEXT may have avoided the panic, but that doesn't

The Table component displays a Select Button for selecting elements and a Done Button disabling that state. These buttons seem to be breaking something about navigation on iOS 18.4.1. It's a nondeterministic issue… but tapping the buttons seems to lead to some corrupt state where the app transitions out of OrdersView and back to TruckView. If the find a bug in the sample code please file a big report via Feedback Assistant and post the FB number here once you do. Bug Reporting: How and Why? has tips on creating your bug report. Is there any public documentation for me to learn about the Select and Done buttons? I don't see anywhere for me to learn about how these work and what my ability is to customize their behavior. Are you referring to the dismiss environment property? If you are then checkout the API docs on dismiss and DismissAction

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