smb big sur

Unfortunately, users of my different apps also started reporting another issue that could be related: paths on an external volume, such as one mounted by NTFS for Mac, or a path on a Synology volume, are converted to / (Macintosh HD) after going through laundry. Could someone at Apple confirm whether this is also a known issue? I'm not sure. There was an issue (fixed in macOS 26.1*) that prevented SMB volumes from remounting during bookmark resolution, however: I believe resolution simply failed; it didn't lead back to /. The issue effected remounting the volume, not the full resolution. *Note that the bookmark will need to be recreated. That also wouldn't explain NTFS for Mac, as that's a local volume mount which presents very different issues. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Absolutely, although it is not much of a test project: https://github.com/martonfarago/documentPickerTest Using this I can pick a folder on an SMB share just fine under 18.7 but can not under 26.1. Thanks for the help.

Yeah, it will be a really big surprise if using .glassEffect(_:in:) triggers a crash in the latest iOS. So as @darkpaw said, providing more details about your issue will help clarify. Regarding #available, you can definitely use it to check the OS version. The following code behaves differently on iOS 26.1 and later: if #available(iOS 26.1, *) { print(iOS 26.1 and later) } else { print(Before iOS 26.1) } Best, —— Ziqiao Chen  Worldwide Developer Relations.

@DTS Engineer It concerns SMB shares of NTFS volumes hosted on Windows PCs. The starting URL could for example be file:///Volumes/Videos/, but the resolved URL is file:///. This happens immediately after resolving the bookmark data, even if that data has been created in the same code context. To be clear, only in macOS 26.1. In older macOS versions the starting URL and resolved URL are identical. FB20917638 contains instructions and a sample project to reproduce the issue.

Since macOS 26.1, creating bookmark data based on a NSOpenPanel URL does not return the expected bookmark data when the selected source concerns a Windows NTFS fileshare. What are you accessing here? Is this an SMB share of an NTFS volume or a NTFS volume you've directly mounted? If it's directly mounted, is it mounted through our read-only driver or a 3rd party file system driver? If this is an SMB share, what's the sharing device? In essence, the following code line with 'url' based on an URL from a NSOpenPanel after selecting the root of a Windows NTFS share creates an incorrect bookmark in macOS 26.1: What is the starting URL and what do you get when you resolve the bookmark? Is there any intermediate activity (like an unmount/remount) or does this happen when you immediately resolve the bookmark? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Never use the comments feature here in the forums. They don't trigger notifications and people don't notice them. This was an annoying bug for me so I wanted to double-check and close the loop. Otherwise, I might have forgotten about it and never seen your comment. But my bug does seem to be fixed. I actually got thrown off when you said NTFS. I was thinking about the NTFS driver. You're actually talking about SMB file shares. I just tested that and it seems to work fine for me. However, I have a special use case. I don't actually need to look at the data. But curiously, the bookmark I restore is NOT the same one I saved. When I save a bookmark to the root filesystem of the startup volume, the url I decode is file:///.nofollow/. So dig into your code and see if the url you are decoding from the bookmark is actually the same url you encoded. I'm not seeing this behaviour on a network volume, but I'm using a Mac as a server.

My question is: Is this pattern—creating a new, temporary ModelContext inside each of these entities(for:) functions (and presumably inside all the other required query/data-import functions for all of my entity types)—the correct way to bridge the gap between the UUID requirement from AppEntity and my PersistentIdentifier-based actor? Yes. ModelContext.init(_ container: ModelContainer) returns a nonisolated context. In case you don't use the context and its associated model instances outside of the current actor, you will be fine. My question is: Is there a recommended way to convert a PersistentIdentifier into a String (to pass to the intent) and then reliably convert that String back into a PersistentIdentifier inside the intent's perform() method? There isn't. In Core Data, NSManagedObjectID provides uriRepresentation(), which returns a URL that can be converted to a string and vice versa. PersistentIdentifier instead exposes an id (ID), which is opaque. The alternative seems to be passing the UUID string

Ed addressed your specific question, but I want to address about the big picture… It seems like your goal is to downgrade an iOS device from a newer version of iOS to an older version. There’s no supported way to do that [1] on iOS or any of its ‘child’ platforms [2]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] The only exception being during the beta cycle of a new OS, where it’s possible to erase and device and install the most recent non-beta OS. [2] It is possible to do this with macOS.

I sympathise with you. 🥲 SwiftUI may be great in some aspects, but I often find that fine tuning to achieve a precise UI behaviour is a nightmare. When it is impossible to understand why SwiftUI reacts in a certain way, you end up spending enormous time just to turn around SwiftUI to mimic UIKit behaviour. Big sigh.

I too have this issue. It prevents audio recording on both the iOS screen recording as well as 3rd party apps like AnyMiro and Reflector 4. This is a big problem for me as I try to make demo videos of my app.

There are three different questions here, so let me tackle them in turn. [quote='805211021, nikhil2701, /thread/805211, /profile/nikhil2701'] Are the Wifi-Aware's WAEndpoint’s discovered ephemeral? [/quote] That’s a matter of definition (-: Our recommendation is that you treat an endpoint like other networking objects, that is, it’s fine to continue using it while your app is running, but it’s best to drop it when your app gets suspended [1]. Also, keep in mind that you can only connect while the publisher is still running, and that gets increasingly unlikely as time goes by. [quote='805211021, nikhil2701, /thread/805211, /profile/nikhil2701'] What is the impact on the infrastructure wifi here in comparison to using the Apple peer to peer wifi … ? [/quote] Wi-Fi Aware certainly can have an impact on infrastructure Wi-Fi. I don’t have any concrete info about that impact, or how it compares to Apple peer-to-peer Wi-Fi. However, you will likely see a difference depending on how you use Wi-Fi Aware, and specifica