smb big sur

Bug number: FB20072274 Title: (SMB Disconnect Causes macOS Disk I/O Call open () to Hang for 10 Minutes). You may have already gotten this through bug feedback, but this is actually a side effect of how the volume was mounted. The default when mounting through mount_smbfs is a hard mount which, among other things, ends up using the default response timeout (~10 min). However, you can also mount as a soft mount: mount_smbfs -o soft …at which point syscalls should fail after ~1 min. Soft mount is what the Finder uses (which is why this hadn't come up before), however, if you were mixing mount_smbfs and Finder mounts to the same server. I think the behavior here might actually come from the session itself (not necessarily the individual mount), in which case an existing mount_smbfs might alter the behavior of the Finder mount. Note that this could also be overridden using forcenewsession on the mount. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Getting back to this a bit late... I don't know if specialData needs to be placed in sendData or sendCommand. I have tried various data structures, but none of them work. Looking over your code, I see two things that concern me: First, I believe command type 2 is for command ack's, so I think that should be 1 instead. I don't think you're accounting for endian-ness. The ISO-15740 spec is written using big endian notation (sensible), but the actual endian format is transport defined (not sensible). In the case of USB, I believe that means everything is little endian. Lastly, we have an old sample project named PTPPassThrough in the documentation archive. I'm not sure how hard it would be to get it working*, but it does provide an example of how to build commands. *Shockingly, the only build error I got was that Xcode couldn't find the 10.6 SDK (yes, SnowLeopard!), but I don't have the hardware at hand to see if it actually works. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

What could be causing push notifications and call notifications to not work in the terminated state on iOS, especially in production/TestFlight builds? So, the big question here is do notifications work properly when your foreground. Based on that answer: Notifications do NOT work in the foreground, meaning notifications don't work at all-> The problem here is likely tied to how you're actually sending the push notification, most typically that you're sending your pushes to the wrong environment (for example, the app is using the sandbox but you're seeing pushes to the production server). This article has a good overview of what that involves. Notifications work in the foreground but do NOT work in -> There's a problem with your app that you need to debug and fix. The larger APNS system has no idea what your app/device is doing, so application state like background/foreground/terminated has NO effect on whether or not a push can reach your device. What does change behavior here is issues in you

The property you're referring to (usesClassicLoadingMode) is available on 18.4+ (wouldn't help for my users who are on iOS 17 and early 18) and it's true by default on the shared URLSession which I use throughout the entire app. I don't use any other session, no custom configurations. I just use Task a lot. Yet I still get crash reports from users on 18.6.2. Therefore I think it's safe to say it doesn't help. As per the crashlogs -> I would most certainly and happily get rid of a third party one, but it delivers more reports that Apple's own one. Perhaps I am doing something wrong but in the Organizer there's just less of them. Looking at Organizer though, the same crash report is also there and when I open the .xccrashpoint and dig in the folder structure and open any of the .crash items in the Logs directory, the same thread crashes occur: Thread 10 name: Thread 10 Crashed: 0 libdispatch.dylib 0x00000001a181de08 _dispatch_source_set_runloop_timer_4CF + 36 (source.c:1349) 1 CFNetwork 0x000000019ae29ed8 UR

My reasoning is difficult to phrase in a way that will not come across as combative or insulting, but suffice to say I explicitly object to the existence of most--if not all--of the features that Apple has shipped in more recent releases and prefer to keep them all out of my house so to speak. I only update the OS when a machine dies and I have to buy a new one. If there's a solid guarantee that all of this is better in 15 then I'll absolutely bite that bullet anyway, but right now I'm essentially just doing a feasibility study and cannot destabilize everything else in my world just to find out whether or not maturity has crept in. My goal is simply an app with an overly-privileged helper that will never appear in any app store or be run on any machine that doesn't belong to a person who immediately disables SIP as a matter of principle. I've already removed all the PackageBuilder stuff as it was very much in the way of testing--that was the only sample project I could find that was close to what I wanted but

@DTS Engineer Updated to RC and sadly, no changes on the big screensaver bugs. FB19204084 is by far the worst. Our workaround for it is imperfect and I had reports from users where in some circumstances, something gets messed up and after that macOS will just refuse to try to launch the 3rd party screensaver (giving users a black screen). Only fix in those scenarios is to restart macOS, which is the worse thing I can tell a mac user to do.

@gravity_gunner I’ve run into exactly the same issue when trying to list the contents of a folder selected through the document picker on an SMB share. I noticed you had mentioned filing a bug report about it, but unfortunately the links you shared don’t open for me, so I can’t check the status. Have there been any updates on this problem, or a known workaround?

Here is a simple view to demonstrate the issue struct ContentView: View { @State private var isPresented = false var body: some View { VStack { Button(Test) { isPresented = true } } .alert(Test, isPresented: $isPresented, actions: { Button(Delete All, role: .destructive) {} }, message: { Text(Are You Sure?) }) .padding() } } Which results in The destructive button is almost unreadable. WCAG score is 1.4, far below the minimum recommended 4.5. I found this post on SO going back to Big Sur, but not on this forum. Any known workarounds (except for building my own dialogs, which I am trying to avoid)? Using confirmationDialog instead of alert does not make a difference.

Seeing the same issue on beta 9. This is a big blocker for us.

[quote='856714022, pnelson, /thread/798550?answerId=856714022#856714022, /profile/pnelson'] I think this is just how macOS 15 and 26 work. [/quote] Ah, cool. I thought we’d broken something in macOS 26 (which wouldn’t come as a big surprise). [quote='856714022, pnelson, /thread/798550?answerId=856714022#856714022, /profile/pnelson'] Not sure why its UI stays up. [/quote] Yeah, that’s just weird, and I do think it’s worth you filing a bug about it. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Bug number: FB20072274 Title: (SMB Disconnect Causes macOS Disk I/O Call open () to Hang for 10 Minutes). I don't think the system will prevent you from reading or writing to a file that's been opened with O_EVENTONLY (assuming you pass in the necessary option). The main risk is exactly what you'd expect, namely that it won't prevent unmount, which could risk data loss. I tried that. The I/O does happen even with the O_EVENTONLY flag, but it still doesn't solve the timeout problem. I think that's the only option if you're specifically using the pattern of opening the file handle and performing I/O to it over time. In addition to reading whole file, I have a use case to read stream of data and not the entire file at once.