smb big sur

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) { ... }

Following my previous post about switching from a business to individual account, I finally received a response from Apple Developer Support. Here's what they told me: From your email, I understand you would like to revert your organization account back to an individual. Once an account has gone through a migration from an individual to a company, this action cannot be undone. I know you mentioned you planned on closing the business, we can disable your team account. You would still be able to take advantage of our Xcode Program. However, you would not be able to publish apps on the App Store. This is incredibly disappointing and frustrating. The email I use for my Apple ID is over 20 years old. I now need to create a new Apple ID to handle Development. This account is essentially broken forever because Apple decided that account migrations should be one-way with no possibility of reversal. What's most infuriating is that Apple never clearly communicated this limitation before I migrated to a business account

Let me start here: And problem is following: when user starts outgoing PTT, PTT Framework plays audio notification, but in case of enabled .voiceChat mode that sound is playing distorted or not playing at all. I don't think the voiceChat mode itself is the issue. The PTT Framework is directly derived from CallKit, particularly in terms of how it handles audio, and CallKit has no issue with this as our CallKit sample specifically uses that mode. However, what IS a known issue is problems with integrating audio libraries that weren't specifically written with PTT/CallKit in mind: As I've mentioned before our app uses PTT Framework to record and send audio messages. In one of supported by app mode we are using WebRTC.org library for that purpose. Internally WebRTC.org library uses Voice-Processing I/O Unit (kAudioUnitSubType_VoiceProcessingIO subtype) to retrieve audio from mic. The big issue here is that most audio libraries do their own session activation and that pattern doesn't work for PTT/CallKit.

Quick comment here: Alas, no change running 14.7.4 on the server. Since this is effecting a particular device, one think I would try here is to try and reset the file sharing system as completely as possible. Basically, delete the existing configuration, turn of smb, restart the machine, turn everything on again. Does the volume(s) you're seeing this in have the Ignore Ownership on this volume checkbox checked? Yes for the external drive, no for the internal drive. (I tested both cases.) If this is designated shared volume, then I would turn that setting off and properly configure the volumes permissions. I can imagine the file sharing daemon enforcing this requirement when using a cache (if it actually does use a cache). Ahh, no. This is definitely not a requirement we'd try and enforce outside the kernel. The check itself is fast enough that the cost of trying to maintain a somewhat current cache (just for empty) would higher than the performance gain. The Finder caches the directory size because t

Is this the expected behavior for userIdentifier to change over time? Yes. As described in Understanding how Live Caller ID Lookup preserves privacy, one of the major architectural goals is to make it impossible for your server to reliably connect users to their activity. A big part of that is not providing a stable identifier. If this is not intended, could this be a potential iOS bug? As I said, the behavior is absolutely intentional. If yes, is there a specific TTL (time-to-live) for userIdentifier? No and maybe. We haven't documented any specific value and I don't think we will, as there is a history of this sort of exact behavior being used to attack this type of protocol. However, there probably is an upper time boundary above which you could discard the tokens knowing they will never be used again. I'm checking with the engineering team to see what guidance I can provide. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

So, I've been going over everything that's been sent and there are few points I want to revisit and think about again: If I try to list the directory on the target (14.7.1) system Is 14.7.1 when this specifically started happening? There was a significant issue with security scoped bookmark resolution that was introduced in 14.7.1 and was only resolved in 14.7.3. I ask because of this point: After restarting the server and reconnecting to the remote volume, ls and xattr succeed without error. The bug above was caused by issues with the keychain not unlocking when the system expected and that could explain the behavior above. That is: The server launched at boot, couldn't get access to the data it expected and was left in a broken state. The server was reset, returning to normal operation. (speculative) Sleep/wake issues can end up causing keychain issues as well, which could recreate #1. In a different direction: Is the server machine logged into by multiple users? Does the volume(s) you're seeing this in hav

So, let me start with the basic issue here; P.S. the return value for vnop_strategy is indeed omitted. So, the first thing to understand here is why VNOP_WRITE and VNOP_STRATEGY both exist. Stat with VNOP_WRITE: * @discussion VNOP_WRITE() is to write() as VNOP_READ() is to read(). The filesystem may use * the buffer cache, the cluster layer, or an alternative method to write its data; uio routines will be used to see that data * is copied to the correct virtual address in the correct address space and will update its uio argument * to indicate how much data has been moved. The critical sentence here is: The filesystem may use the buffer cache, the cluster layer, or an alternative method to write its data In other words, VNOP_WRITE does NOT have to actually write anything to disk. Most of the time, it will actually be moving the data into the cache to be written out to disk at some later point. Moving to VNOP_STRATEGY: * @discussion A filesystem strategy routine takes a buffer, performs whatever manipulations

[quote='774718021, Roland4711, /thread/774718, /profile/Roland4711'] But my question is if this is really how things should work. [/quote] Well, it kinda depends on your definition of “should” (-: As things currently stand, if an API is not annotated correctly then the only way you hear about it is via a trap at runtime. This isn’t ideal, as you’ve noted, but it’s better than the Swift 5 behaviour, where your callback ends up running, but on the wrong thread, potentially corrupting things as it goes. As to the big picture, I think it’s safe to say that there’s significant demand for improvements in this space (-: In fact, Swift Evolution has recently published a “vision” document that’s covers this overall issue. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The issue is actually here: Mac-mini:test alan$ xattr -lr /Applications/apps/VAquaManager.app /Applications/apps/VAquaManager.app: com.apple.macl: The macl refers to Mandatory Access Control List. We've never formally documented this, but they're a mechanism the system uses to try and further constrain processes ability to interact with data the user has not granted them access to, particularly the ability to destroy data as well as modify it. I don't think a standard copy would have generated a MACL*, however, you specifically did not ask for a standard copy. You used ditto, which tries to create a more exact duplicate of the original object, even when those semantics restrict access that object. *More specifically, if it did generate a MACL, that MACL would have been scoped to the creating process, which should have given unrestricted access to the newly created object. Mac-mini:test alan$ ditto /Applications/apps/VAquaManager.app VAquaManager.app It seems odd that FinderInfo extended attributes were presen