smb big sur

Thanks Quinn the Eskimo! I don't like that quite as much, because then all logs from my lib will be at the same level (the one passed in by the user of the lib). The something-is-very-broken logs would be drowned out in a sea of debug logs. For example, there are debug logs that emit on each audio buffer coming from the mic, containing the sample count in the buffer. These are frequent and only meant to be 'turned on' when I'm trying to debug an issue. I'll share what I ended up doing. It makes log lines a little cumbersome for me, but thankfully users of my lib don't have to deal with that. import OSLog public enum AIProxyLogLevel: Int { case debug case info case warning case error case critical func isAtOrAboveThresholdLevel(_ threshold: AIProxyLogLevel) -> Bool { return self.rawValue >= threshold.rawValue } } internal var aiproxyCallerDesiredLogLevel = AIProxyLogLevel.warning internal let aiproxyLogger = Logger( subsystem: Bundle.main.bundleIdentifier ?? UnknownApp, category: AIProxy ) // Why not cre

[quote='827663022, stang2021, /thread/775724?answerId=827663022#827663022, /profile/stang2021'] I suspect if it is the problem in the way I created the self-signed certificate [/quote] That seems unlikely, given that you’ve completely disabled server trust evaluation on the client. If you’re concerned about a TLS issue, one easy way to eliminate that from the equation is to use the same credentials for a TLS-over-TCP server. If that works, you know your credentials are good. Is the client connecting with a .hostPort(…) endpoint? Or with a .service(…) endpoint? If it’s the latter, try testing with the former. That removes Bonjour from the equation. You set an ALPN, which also complicates things. Try removing that. [quote='827663022, stang2021, /thread/775724?answerId=827663022#827663022, /profile/stang2021'] the server hit the failed state with dns error [/quote] A DNS error? Weird. What error exactly? ps While it’s almost certain not the cause of your curent issue, this: connection.start(queue: DispatchQueue.

First off, anecdotally, the sandbox (vs production) push system seems somewhat more susceptible to this sort of failure. From looking at lots of logs, the underlying issue seems to be that the system prioritizes establishing the production connection (for obvious reasons) and under the right/wrong conditions that can mean the sandbox connection ends up offline much longer than the production connection. That doesn't mean you won't see the same issues in production (you absolutely will), but my experience is that you will see this more in the sandbox. Next, moving to here: After a short delay, the push notification is eventually received. How short is short? More broadly, what's the delay that's actually problematic to you? My general experience here is that voip push latency from server submission to end device is ~4s and that anything less that ~10s should be considered normal behavior. Much higher delays than that are absolutely possible (see below), but that 4->10s range is what I recommend developers t

I am getting the same problem as OP on few public quite big websites in EU country. However in console under trustd I see something different: SecKeyVerifySignature failed: Error Domain=NSOSStatusErrorDomain Code=-67808 RSA signature verification failed, no match UserInfo={numberOfErrorsDeep=0, NSDescription=RSA signature verification failed, no match}

I am getting the same problem as OP on few public quite big websites in EU country. However in trustd I see something different:

Anything involving local network restrictions should be easy to debug. Construct a program that fails. Then try it on a non-local connection. If it consistently works there and fails locally, then you've definitively confirmed that it's related to local networking. However, there were more changes in macOS 15 than just local networking. There are two big issues that end users encounter. Firstly, macOS 15 adds a new feature called Private WiFi address and defaults it to rotating. As someone who sometimes does interesting networking myself, I immediately changed that to fixed. This is not my problem to deal with. You can also change this setting to fixed and see if that eliminates the problem. Most people encountering problems are willing to change this setting to fixed. Next, macOS 15 mades some low-level networking changes that broke many VPNs and network filtering apps, including Apple's own Application firewall. It turns out that most people really don't understand networking and believed that the

However, keep in mind that this is a problem in the other direction as well. That is, the client cannot delete all the files it knows about and then assume the directory is empty, as someone else can be creating files at the same time it's deleting them. I don't believe that this particular problem can be blamed on interference from other known parties, such as Finder or MDS. Such interference would only temporarily prevent a directory being deleted. As far as I can tell, the inability to delete the directory persists until File Sharing is restarted. (I'm not worried about rogue agents that perpetually create and delete files.) Recall that after restarting FIle Sharing, the client regained the ability to list the directory tree. Just now, in this state where clients can list the directory tree, I made another attempt to delete the (remaining) tree, and it failed (but not at the same directory). Mac-mini:test6 alan$ rm -rf V* rm: VAquaManager.app/Contents: Permission denied rm: VAquaManager.app: Permission den

Hi @monono I'm fairly confident I can help you make dynamic entities intractable. Here's a snippet that dynamically creates intractable entities. To run it: Download the sample code project Transforming RealityKit entities using gestures. Copy the Extensions and Components folders from ./Packages/RealityKitContent/Sources/RealityKitContent/ into your project. Important: add code to your app initializer to register the component. init() { GestureComponent.registerComponent() } Add the snippet to a volume. Note the same logic works in a RealityView in an immersive space. struct ContentView: View { let root = Entity() var body: some View { VStack { RealityView { content in content.add(root) } .installGestures() Button(Add entity) { addNewEntity() } } .padding() } func addNewEntity() { let size:Float = 0.08 let mesh = MeshResource.generateBox(size: size) let entity = ModelEntity(mesh: mesh, materials: [SimpleMaterial(color: .red, isMetallic: true)]) // Tell RealityKit the entity is intractable. entity.components.

I updated to Big Sur, it got stuck on progress bar on download. After an hour, I decided to restart the mac, on restart it prompted me to restart because I had an update. I figured what is the worse that can happen. on restart it is now in a loop seemingly installing something. No messages, just a progress bar and the apple logo on dark background. It has not been a seamless experience to update the OS 😥😥

That tells me that the system call did not return an error, which makes me think that the file sharing daemon returned an OK status before it was known that the directory was not deleted. I observed this problem earlier when using my own program to delete. It is what made me think that operations were being performed out of order. I haven't looked at the details in depth but it's possible something like this does occur. From a performance perspective there is a pretty ENORMOUS performance benefit to SMB assuming operations will succeed and proceeding forward with a command stream instead of individually waiting on every single action. However, keep in mind that this is a problem in the other direction as well. That is, the client cannot delete all the files it knows about and then assume the directory is empty, as someone else can be creating files at the same time it's deleting them. Regarding Finder, the client Finder responds quickly when a change is made on the server. I assume it getting notific

Apple have made VNOP_MONITOR() available as a public symbol in macOS 15.4 beta in response to the bug report I submitted, FB16082106. Yep. It doesn't always happen, but the bug process can work. Is there anywhere I could look for VNOP_MONITOR()+vnode_notify() usage examples other than the SMBClient and Darwin/XNU sources as it's not immediately clear how remote filesystem changes are propagated across all connected clients through the use of those functions? A few different answers: In terms of fs drivers VNOP_MONITOR used by NFS and afp as well as smb, but I'm not sure that will show you anything fundamentally different. In terms of what vnode_notify() actually does, the vfs system automatically generates* FSEvent's based on it's own interactions with the VFS driver. vnode_notify() lets a vfs driver manually trigger that process. The basic flow here is that VNOP_MONITOR is how the vfs system tells your driver what the larger system is currently interested in and vnode_notify() is how your driver tel

@DTS Engineer , but the question was: Does LazyVStack and LazyVGrid release views from memory inside a ScrollView? in iOS 18 And not about loading views incrementally. With such a big change, why not make it a separate component? Or at least add a parameter to existing? For example, so it looks like this: ReusableVStack { ... } // or LazyVStack(reuseViews: true) { ... }