smb big sur

[quote='840893022, TinyFish, /thread/785083?answerId=840893022#840893022, /profile/TinyFish'] Your crash report is similar to mine, except for the name of the dynamic library. [/quote] Right. That’s just because my app doesn’t use C++ directly. But both the libraries in question are built-in to macOS and thus I see these results as equivalent. [quote='840893022, TinyFish, /thread/785083?answerId=840893022#840893022, /profile/TinyFish'] Is it possible that it is a bug in macOS …? [/quote] macOS is big enough and complicated enough that literally anything is possible. However, the most likely scenario is that the user changed something without understanding the consequences. My immediate suggestion is that you ask them to check the state of the Open Using Rosetta checkbox, per step 9 of my previous post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks Quinn, I'm sure a new and clean empty project runs, but this is a (big) existing project, objective-c, no storyboard but XIBs, that has run fine before 18.4, for years. As the crash happens before my code is even entered I don't even know where to start! Does this Sanitizer message mean anything to you? What is the problem with MemoryMappingLayout? libclang_rt.asan_iossim_dynamic.dylib__sanitizer::MemoryMappingLayout::Next: 0x10f2dae50 <+0>: cmpl $-0x1, 0x8(%rdi)` With the sanitizers switched off in the Run Scheme the app runs fine in the Simulator, but I have a user that experiences an actual crash on device. That crash is different from what I experience: the app crashes on simulator before entering my code, after displaying the splash screen, while the user has an app that does startup, and can be used for a few seconds, but crashes on a certain input. As is, I cannot even establish if these crashes are related. In the App Analytics in AppstoreConnect I see no increase in the number o

Then VNOP_PAGEOUT gets called. I thought that VNOP_PAGEOUT was only called for mmapped files. No that's not correct, that's definitely not correct. The idea behind the UBC (Universal Buffer Cache) is unify the I/O and VM system into a common architecture. In concrete terms, these to cases: Reading the first 16kb of a file. Mapping the first 16kb of the same file. ...should both return a VM page that's actually backed by EXACTLY the same page in the UBC system. Similarly, writing to the first 16kb of that file and modifying a mapped file both have EXACTLY the same result- that is, they both modify the same page in the UBC. But there are no VNOP_MMAP/VNOP_MNOMAP calls being made for the files being extracted. No, you called cluster_write(), which basically means please modify this pages in the UBC. The current VNOP_PAGEOUT implementation ends up calling err_pageout() for files that didn't get tagged as being memory mapped by VNOP_MMAP. I don't think that's going to end very well. Have you looked at what it's ac

We have a problem in a scenario that SIM lock is disabled so after a phone reboots it has the Internet connection but it is still locked. When you call into the VOIP app the app is not being launched as the result (it seems reasonable because it wouldn't be able to access the keychain items etc...) So first off, yes, this can happen. There are a small number of edge cases (one of which is voip) where the system may launch the app prior to first unlock. This behavior has never been documented and can be somewhat inconsistent, however, it's is also VERY old (it comes the original, iOS 4, voip architecture). Because of that, my advice to voip developers has long been: Don't assume/rely on it always happening. As you've noted the behavior is somewhat odd and there are situations where it will not occur. Be prepared for it to happen and handle it as gracefully as you can/choose. Depending on your app architecture, that could mean handling the call completely or simply reporting and then ending the call. One note o

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