“smb big sur”

The following data is extracted from the .crash report: So, a few points from the log itself: Action taken: none In other words, the system generated this log and then did... nothing. Your app did not crash, nor was there any user visible impact. We use the same format for a variety of different events and many of those logs are informational/diagnostic, not disruptive to the user. Writes caused: 1073.96 MB over 48.28s (Average: 22.24 MB/second) Note that the data rate there (22.24 MB/s) is EXTREMELY slow for our Disk I/O performance. Whatever is going on here is tied almost entirely to network I/O, not the disk itself. Next, I want to start here: ...To stay within the daily 1GB budget Staying below this budget shouldn't necessarily be one of your app’s goals. Storage and I/O are resources that exist to perform work on the user’s behalf. If the user tells you to download a 5GB file, then your app should download that 5GB file as quickly as possible, not stagger the download over 5 days to avoid blowing past t

Welp, I just pulled TipKit from my app as this is still not fixed in iOS 26.5 (23F5043k). I was only using it for one tip, so not a big loss. Still, it’s a shame—TipKit has a lot of potential, but there are too many limitations and paper cuts like this one.

You can set a min and max size in the UISceneDelegate method scene(_:willConnectTo:options:) by accessing the sizeRestrictions property of the UIWindowScene. Here's an example: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let winScene = scene as? UIWindowScene else { return } if let sizes = winScene.sizeRestrictions { sizes.minimumSize = .init(width: 640, height: 480) // No smaller than 640x480 sizes.maximumSize = .init(width: .max, height: .max) // As big as the user wants } }

I’m not aware of any known issue that matches these symptoms. As you’ve noted, iOS is expected to preserve app group containers across OS and app installs. This certainly works for most apps and most users, but that doesn’t preclude there being a bug that causes this problem for some users of some apps. To investigate this we need to see a sysdiagnose log taken immediately after the user notices the problem. That’s gonna be tricky to acquire given that this problem isn’t obviously reproducible. I have a bunch of background on this in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. Key to that process is the ability to quickly and reliably identify that the problem has occurred. If I were in your shoes I’d add specific code for that, code that’s not tied to UserDefaults or Core Data. Both of those are big, complex subsystems, which makes it hard to know whether you’re hitting a problem with that subsystem or something more fundamental. Rather, I recommend that you store this state in fil

What you'll find is that there are two clients— yours and a (presumably unrelated) 3rd party client. The other ES client is basically a 3rd party logger that's not active. Ours does some auth work, but we're fairly certain in this case it's just monitoring to do reporting and follow-up scans. Do you know exactly what kicked off your helper process? Both in terms of the triggering event and the target file? No. At the time, the system had been idle for 2 hours. In this case, we do observe a system update being staged in the background, but not in all other instances. I suspect it was a FILE_NOTIFY_CLOSE. It would be insightful to know if APFS triggers that or related ES events when decompressing a file. A big part of the problem here is that the data we're looking at is being collected LONG (2+ days) after the problem itself actually occurred, which means we don't REALLY know EXACTLY what happened. I will submit unified logs that cover the period in question, but your point remains. That ES check can

So it appears to be the same failure we are talking about here: https://developer.apple.com/forums/thread/814076 I just updated that thread, but the bug described there (FB21805212) was fixed in macOS 26.4. Also, to be clear, the bug was specifically in smb, NOT copyfile itself. However... It has data. I can read the filenames when I view it as 'plain text’. The Resource fork is less than 300 bytes, but that is enough for it to cause copyfile to fail. The total file size is ~12kb. That doesn't sound like the bug above. The bug above was caused by the SMBClient incorrectly accounting for large xattr size, which then caused the copy to fail. I don't think it would have happened with small xattrs (certainly not 300 bytes). FYI, the Finder (and other copy engines) work because they're using the ..namedfork accessor, when it ends up going through a totally different code path in smb. Interestingly, .DS_Store causing problems with copying is infamous enough to have a mention on Wikipedia: Yes, but

Interesting. I didn't realize that. However, it doesn't seem to always work. Yea it doesn't always work. I have a fairly solid hack workaround in place to make it work in my app, which was a bit tedious to put together. There are a few rules I discovered through trial and error. Checking for new custom icon not tahoe' custom icon etc. And a few other tricks for dealing with some other issues. I was a bit proud of myself. I discovered a few folder locations where Finder got the icons wrong but my app got it right. Wasn't meant to last though. I see. My workaround still works, except for the fact that folder colors in my app are now wrong. Kind of a big deal. Been working on this update for a while now and I'm finally close to finished..but just when I thought I was out they pull me back in. I mean I guess I could do the drawing and tinting, etc. myself but really that's like another day at least. Then testing. Sorry I'm not vibing yet with the rest of them. Guess I have to decide whether to go down th

Let me start by saying two slightly contradictory things: It's very likely that there is an APFS bug here, so if you haven't already, please file a bug on this and post the bug number back here. It's ALSO very likely that your ES client (possibly both ES clients) are required to actually experience this bug, and you should address it as well. Next, I think I want to be clear that some of what I'm saying is a bit of an educated guess. A big part of the problem here is that the data we're looking at is being collected LONG (2+ days) after the problem itself actually occurred, which means we don't REALLY know EXACTLY what happened. That doesn't invalidate what I'm describing above, but I do think it's important to have some awareness of the limitation of the data at hand and that, most importantly, new data could totally change our understanding of the overall state of things. Getting into the details: But here, I don't see such things. When EndpointSecurityEventManager is on the spindump, it's only bec

It sounds like you’re using Developer ID signing for day-to-day development. That’s a mistake on multiple levels. I talk about this in general in The Care and Feeding of Developer ID, but there are extra issues with system extensions, where system policy requires that Developer ID signed sysexen be notarised. So my advice in this case. Use Apple Development code signing for day-to-day development. Use Developer ID for pre-release testing and distribution. There are a couple of key benefits with this approach: It lets you build and debug without enabling development mode, which is a big win IMO. Xcode’s automatic code signing works well with Apple Development signing. Even if you’re not using Xcode, you can create a small test project in Xcode, get it working, and then follow the same path it took. See Debugging a Network Extension Provider for specific advice on how to bring up a provider in Xcode. One thing that Xcode doesn’t handle is the -systemextension suffix )-: To learn more about that, read E