smb big sur

Again @Kevin, I'd like to stress how much I appreciate your feedback here. If we disagree on something, it's not a reason to turn this into a heated discussion. ABOUT DOCUMENTATION I really apologize, but I have to touch the subject of documentation once again, I promise it will be for the last time… It may very well be that I didn't get it quite right because of not being a native English speaker. Or maybe even more so because I really liked the existence of old CMPlugin (macOS 10.6 Leopard or older) and hated when it was discontinued (but I admit, it was discontinued for good reasons) that I perhaps immediately saw Finder Sync as a sort of its revival. Those things might have influenced a lot my ideas of potential usage for Finder Sync. But I still maintain that the documentation wasn't clear about its ONLY INTENDED usage (remote content/data syncing). Yes, the very first sentence of the original document says: In OS X, the Finder Sync extension point lets you cleanly and safely modify the Finder’s user int

I have a big revision of the LNP FAQ in the works, but it’s not done yet )-: In the meantime, I can confirm that there’s no mechanism to authorise local network access through a configuration profile. [quote='766178021, this_username_did_not_exist, /thread/766178, /profile/this_username_did_not_exist'] It seems a bit strange considering that this feature has been available on iOS for at least 3 years. [/quote] Right. That suggests that this isn’t an omission, but a deliberate design choice. If this feature is critical to your organisation, I encourage you to file an enhancement request that explains why it needs to to be able to force the user’s privacy settings. 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

Let’s tackle you big picture question first and then come back to the details: [quote='766021021, konradedgar, /thread/766021, /profile/konradedgar'] can I deploy the App on the App Store and use NSAppleScript as shown above? [/quote] Probably not. I don’t work for App Review, and they’re the only folks who can give you definitive answers about what is or isn’t allowed on the store. However: When you use NSAppleScript, the Apple events originate in your process. For a sandboxed process to send arbitrary Apple events, it must be signed with the com.apple.security.temporary-exception.apple-events temporary exception entitlement. My experience is that App Review only approves the use of such entitlement is exceptional circumstances, for example, to work around a sandbox bug on older systems where the bug is fixed on the latest system. If you want a more definitive answer, you’ll need to talk to App Review directly. [quote='766021021, konradedgar, /thread/766021, /profile/konradedgar'] will I need to sto

[quote='766100021, jaikiran, /thread/766100, /profile/jaikiran'] Should this be reported as an issue through feedback assistant … ? [/quote] No. Well, you can report it as log noise if you like, but it’s definitely not a sign of an actual problem. Foundation was created as part of Apple’s (well, NeXT’s) app development story. For this reason it contains a component, UserDefaults, with some helpful, but non-obvious, behaviour: You can override specific user defaults by passing them on the command line. For example, consider this program: import Foundation func main() { print(UserDefaults.standard.string(forKey: QTest) ?? -) } main() If you run it with no arguments it gets nil back for this default: % ./Test766100 - But you can supply a default as an argument: % ./Test766100 -QTest 'Hello Cruel World!' Hello Cruel World! This mechanism supports all property list types. That’s super useful in some cases. For an example of that, check out this post. This log message is being triggered by the property list parser

Be sure to pass in the camera intrinsics. Rather than compute them yourself, pull them from the AVCaptureDevice. I've seen something similar, when the zoom is at default, it's fine, as it increases, the fact that your view is zoomed in isn't known to the tracking system because incorrect intrinsics. So a small offset at low zoom because a big offset at bigger zoom and the system tells the accessory to rotate too much. Feedback loop.

We're having this same issue as well— it sounds like it may share a root cause with a similar issue that has been reported on SFSafariViewController (same behavior, same versions) https://forums.developer.apple.com/forums/thread/764468 I agree with others that this is a big issue

It seems after I bookmarked items on ftm it made a big and now only reports one of the bookmarked items and nothing else shows!

Also, the enumerator mechanism is kinda out old school. A better way to enumerate a directory is with the -contentsOfDirectoryAtURL:includingPropertiesForKeys:options:error: method. This has a couple of important advantages: The keys parameter lets you prepopulate the properties you need on each URL. This is really big performance boost if you’re working with a high-latency volume, like one mounted over the network. It gives you a useful error if it fails. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com