smb big sur

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

es_event_mount_t includes statfs structure. This structure has the field 'f_type' which defines type of filesystem. However, man page says nothing about possible values of this field. Yes, and the short summary is that the value of f_type isn't something that will be all that useful to you (which is what it isn't defined). What is the best way to define file system type? Can I use 'f_type' No. or 'f_fstypename'? What are you actually trying to do? If you're you're purely collecting a value for display/informational purposes, then sure, you can copy that value. However: If so, are there any constants in header files which can be used? ...if you're trying to base programmatic decisions on file system type, well, that doesn't really work. There are there are a two critical issues with that approach: The value isn't stable. You can add new files systems to the system, which means the fields value isn't predictable. The characteristics of a given file system are FAR more variable than most developers expect. As th

This issue is still ongoing. Thus far we have not been able to figure out what is going on but have reduced complaints quite a bit by rolling back to minimum OS / Devkit of iOS 17. So it is some kind of bug or behavioral issue with iOS 18 SDK. We cannot find a pattern to it other than that most users are in Europe and are not using iCloud to backup. This means we are using the NSPersistentCloudKitContainer regardless of if users enable or do not enable iCloud usage. This might be the root so if anyone is aware of what might have changed in iOS 18 that would do this PLEASE let me know. We have also now default always enable iCloud usage without asking if we find an account present. They can turn it off (with big warnings) if they want but we no longer ask on launch. Also we will investigate not always using NSPersistentCloudKitContainer if iCloud is not used.

I have been sitting with samba and my driver with dtrace for around a week, comparing every field and every return code. So, the risk with this kind of comparison are details (and differences) like these: I do not have MNT_DOVOLFS in mount flags. AND For persistent object ids (VOL_CAP_FMT_PERSISTENTOBJECTIDS), I do have this one enabled, however, I am not sure I am doing anything to actually support it. The behavior of a VFS driver isn't just determined by the data it directly returns. The details of how you describe your own capabilities to the system because the can and will change: How the VFS system interact with your driver and interprets your data. How user space process choose to interact with your files system. Claiming your files system support a capability it does not will create EXACTLY the kind of problem you're seeing. Based on what you're said here: Afterwards, even renavigating back to my root will not work inside Adobe - the driver will simply represent itself as empty. I'd also sugge