smb big sur

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.

First off, as a quick confirmation, do you see this behavior when you’re using another Mac as the SMB server? I don't think you will, but that's worth confirming. Even with a different Mac running as a server, a 10 min timeout was observed. OK. Please file a bug on this and post the bug number back here. I think passing O_EVTONLY into open would work; however, I'm not sure that's really usable for I/O. O_EVENTONLY is only used for watching files like file modification, file renamed, deleted, etc. It can't be used in this context. 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. Note that the other option here would also be to pass in O_NONBLOCK and shift to non-blocking I/O. I'm currently using blocking I/O. Shifting to non-blocking I/O is the only way for faster timeouts? I think that'

I'm now lamenting ever supporting the iPad. It seems that device is just not playing nice. In SwiftUI you're supposed to be able to use .windowResizability(.contentSize). On macOS, I use that along with modifying my main view with .frame(idealWidth: 1024, idealHeight: 768) and this forces the window to have a content area of that size. tvOS is a non-issue since you're always dealing with 1920 pt x 1080 pt screens. iPhone also a non-issue at least for my games. But with iPad and iOS 26, even if attempting something similar as for macOS, you really don't have ultimate control. I was able to at least set a min of 360 and max of around 500 for the iPad window. But attempting say 720 x 720 will fail since a user and/or system can resize the window. And even when using Canvas, content will now be offscreen. Example (see attached). The actual window height is around 560 pt. So querying the size parameter to Canvas seems to be useless if wanted to use to drive how big to render things. Apple made a huge mist

First off, as a quick confirmation, do you see this behavior when you’re using another Mac as the SMB server? I don't think you will, but that's worth confirming. Even with a different Mac running as a server, 10 min timeout was observed. I think passing O_EVTONLY into open would work; however, I'm not sure that's really usable for I/O. O_EVENTONLY is only used for watching files like file modification, file renamed, deleted etc. It can't be used in this context. Note that the other option here would also be to pass in O_NONBLOCK and shift to non-blocking I/O. I'm currently using blocking I/O. Shifting to non-blocking I/O is the only way for faster timeouts?

Following the topic of intercepting file access events: could you suggest other technologies that are better suited to achieve this goal? So, I think the big question here is what are you actually trying to do“? The core problem here is that: Read I/O is REALLY frequent, so the system doesn't want to do anything that would make it slower/more complicated. Memory mapping makes the idea of tracking reads somewhat... questionable. As the most extreme example of this, take the file that's the backing libsystem.dylib. EVERY (yes, EVERY) process in the system has mapped it into memory and is accessing it very frequently. Tying any I/O activity on that file to any specific process isn't really possible or meaningful. Even if you could track actual I/O activity (meaning, read from disks) and tie it to a particular process, all that would tell you is which process happened to ask for a page I didn't have. It wouldn't tell you anything about the other X processes that accessed the data directly from VM without