About a year ago, I developed a FinderSync extension for a MacOS desktop app, and included a custom icon to display in the sidebar and Favorites. And it worked. Fast forward a year -- there have been changes to the containing app, and the custom icon has disappeared. I know the main app had moved to using an asset catalog for its app icons, which according to https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/Finder.html#//apple_ref/doc/uid/TP40014214-CH15 prevents the template-image sidebar icons from working. So I followed the steps described on that page: I switched off the asset catalog, added a non-catalog iconset with the appropriate icon and sidebar files to both the containing app and the extension, and made sure that the Info.plist for both programs included a CFBundleIconFile entry set to the iconset name... but that didn't fix it. (I do know that the asset catalog is still part of the main-app build, to supply other icons; all I did was switch off the setting to use it for the app icon.) The .iconset folder contains the 10 normal icon .png files, and the six sidebar .png files; it compiles into an .icns file, which is successfully included in the build... but if I open that .icns file in Preview, it only shows the 10 normal icon sizes, not the sidebar files. So what have I missed? How do I get iconutil to include the sidebar_ files at build time? And how exactly does the FinderSync extension locate the image to use for the sidebar icon? What other settings do I need to check?

I'm updating a utility which mounts a virtual drive; I want that drive link to be available in Finder's Favourites sidebar when it's open, the same way that the Dropbox folder's link displays. Under OSX, I was able to use LSSharedFileListInsertItemURL, but this has long since been deprecated. What's the current best-practice way to add something to that sidebar programmatically at runtime, using Swift? (If best practice is just not to do it -- how does Dropbox get away with it?)

OK, bit of archaeology here... I'm trying to update an old project (mixing C++ and Swift) which dates back to Swift 3 / XCode 8 / OSX 10.11. I used User Migration to bring the whole user account onto a new Big Sur VM (11.4), then installed XCode 10.1 (the last version which could upgrade Swift 3 to 4) and started to build it. I got a whole string of permission errors on files -- .h's which were created by the same user, and which were even present in other targets in the same project. These could largely be fixed by opening the files manually in xcode, and in one case explicitly adding it to the same target. Then at linking I started getting the same errors on my boost dylibs -- errno 1, operation not permitted. I'm assuming this is a sandboxing issue -- so far granting XCode Full Disk Access seems to have gotten me past that problem. But is there a correct way of handling this?

Been un-mothballing an old Swift 3 project and upgrading it to Swift 4, for which I need XCode 10.1. Set up a new VM (Big Sur 11.4), migrated the whole user and project with User Migration, and built the project. All the code is compiling, but during the "Compile Asset Catalogs" phase, it reports "Command CompileAssetCatalog failed with a nonzero exit code". Inspecting the output reveals that it's running actool, which is returning with a "Bus error: 10". I can re-create it from the command line with the same arguments. Or without them. Simply running actool with any arguments gets that error. On the old working system, running /Applications/Xcode.app/Contents/Developer/usr/bin/actool -? produces an XML error message. On the new system, it produces "Bus Error: 10". So it doesn't matter what code is being compiled, the entire actool is malfunctioning. (The new system also has a /usr/bin/actool on the path -- same problem.) UPDATE: I got a bit more info from running actool from the other admin account (the one that was on the machine before I ported the old machine's account). Here's the misfire: sh: line 1:  1468 Bus error: 10           /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -find actool 2> /dev/null actool: error: unable to find utility "actool", not a developer tool or in PATH Curious that the SDK that's been referred to is OSX 10.14, when I'm running 11.4! Will XCode 10.1 work with a more up-to-date SDK? Anyone got any ideas on this? I suspect there may be a permissions issue somewhere -- when I first tried to build the project on the new machine I got a whole string of EPERM errors, which were resolved by giving XCode permissions for Full Disk Access. Does "Bus Error" suggest in this context an attempt to access protected memory or something? Where should I look?

Hi -- I'm working on a macOS FileProvider extension which needs access to the same keychain as my main app (to retrieve the app's Dropbox access token). I've set both programs up in Xcode to use a Keychain Access Group ($(AppIdentifierPrefix)com.orexresearch.EMPSecure.Shared), and to make sure it uses the group, I'm writing the token to the shared group using the kSecAttrAccessGroup attribute: queryDict[kSecAttrAccessGroup as String] = "CD......7C.com.orexresearch.EMPSecure.Shared" as AnyObject? The main program reads and writes the token successfully. But the extension cannot read the entry either with or without that attribute -- it produces an error -25300 (errKCItemNotFound), and if I try to write to the keychain it produces CSSM Exception: -2147415840 CSSMERR_CSP_NO_USER_INTERACTION. (Presumably this is saying it doesn't have default access to the keychain, and the system is blocking its attempt to pop a dialog to let the user select Allow.) Any ideas what I'm missing?

I've built a macOS app (in Xcode 12.5) with Finder extensions, and set all the components to share a common app group, with the name correctly formatted as CD......7C.com.orexresearch.EMPSecure.group . Up till now, it's been working fine for everything I've needed it to do, with app and extension both accessing common files. But now I need to do file downloads for the FileProvider extension, and these are failing. I know part of the problem is to do with the App group -- in the main app, the download works if I initialise the Dropbox component without the app group identifier, but if I switch Dropbox to use the app group identifier, it fails repeatedly in both the main app and the extension: error 21:36:44.487814+1100 EMPFileProvider BackgroundSession <7764EC70-AC7F-46F4-91DC-547FAA23249C> an error occurred on the xpc connection to setup the background session: Error Domain=NSCocoaErrorDomain Code=4097 UserInfo={NSDebugDescription=} error 21:36:44.487893+1100 EMPFileProvider BackgroundSession <7764EC70-AC7F-46F4-91DC-547FAA23249C> connection to background transfer daemon interrupted error 21:36:44.487935+1100 EMPFileProvider BackgroundSession <7764EC70-AC7F-46F4-91DC-547FAA23249C> connection to background transfer daemon invalidated (A slight variation on the first message visible from the main app: 2022-01-15 21:25:11.726914+1100 EMPSecure[90774:2908614] BackgroundSession an error occurred on the xpc connection to setup the background session: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.apple.nsurlsessiond" UserInfo={NSDebugDescription=connection to service on pid 0 named com.apple.nsurlsessiond} ) This appears to be lower-level than anything to do with the Dropbox toolkit, but it only occurs with the app group setting for Dropbox downloads. And in both components, the following errors are logged on startup: default 19:56:47.424357+1100 taskgated-helper allowing entitlement(s) for com.orexresearch.EMPSecure.EMPFileProvider due to provisioning profile (isUPP: 0) error 19:56:47.428323+1100 taskgated-helper com.orexresearch.EMPSecure.EMPFileProvider: Unsatisfied entitlements: com.apple.security.application-groups error 19:56:47.428338+1100 taskgated-helper Disallowing: com.orexresearch.EMPSecure.EMPFileProvider The odd thing is that the other functions I've been using the app group for -- access to common files in the group container's Library/Application Support folder -- appear to be being allowed just fine. Even though it says the entitlement is unsatisfied! In both components, the "App Groups" section is visible on the "Signing & Capabilities" tab of the Xcode target in my app, the full group name CD......7C.com.orexresearch.EMPSecure.group is present, and the .entitlements file for the project has one item under "App Groups" set to the same value. There is also a "Keychain Sharing" group, CD......7C.com.orexresearch.EMPSecure.Shared, which seems to be working fine. So what else do I need to do to address these errors? (Note that as this is macOS; I've configured the app groups locally rather than through the website. If I go through the website, the "App Groups" entry under "Capabilities" is greyed out -- not just for me, but for the admin/account-holder of our team! Is this a sign of a bigger problem?)

Hi -- my company built an internal macOS app using the SwiftyDropbox toolkit, which has been working fine... with the one oddity that since we started installing it on Monterey, on some machines (not all) on first run it now asks for permission for keychain access (for the Dropbox token). The bundle ID and so forth are correct; that's not the problem. The issue is just, how is it possible to pre-approve this keychain access? (It's clearly possible, since the dialog never appears on some machines.) Can it be allowed as part of the installer process, after the Administrator password is entered? Or at the very least, is it possible to request access for the app at that point, rather than later when the app is actually run?

I'm working on a FileProvider which allows access to encrypted files in Dropbox; I can successfully read and present the decrypted files, so I know it's basically working. But I'm having problems getting FileProvider to re-enumerate a folder when its encryption status changes. When the FileProvider receives an update notification saying a folder is now encrypted, I use signalEnumerator to re-enumerate the folder: FileProviderExtension.manager?.signalEnumerator(for: existingItem.itemIdentifier, completionHandler: { (ourError : Error?) -> Void in       if let ourError = ourError {           log("notifyCallback: mount / unmount failed re-enumeration: \(ourError)")       } else {           log("notifyCallback: mount / unmount signalled re-enumeration; pending")       } }) The log reports that the re-enumeration is pending... but as far as I can tell, neither enumerateItems nor enumerateChanges is called on the folder's item unless a Finder window is actually open for that folder. This means that, when an app other than Finder tries to access the files through the filesystem, it doesn't see the updated set of filenames. (For further reference: I've added code to both enumerateItems and enumerateChanges, so that if the call has been triggered by a recent folder-encryption notification, it retrieves a complete set of items from the Dropbox folder. If a retrieved file has an encrypted filename, it reports it as a modified item and returns its filename in-clear; if the filename isn't encrypted, it doesn't return the item (for enumerateItems) or returns it as a deleted item (for enumerateChanges). This approach seems to work successfully for listing folders with a constant state; it's only if the user encrypts / decrypts a folder without currently having a Finder window open inside that folder that I'm not seeing a refresh.) Any advice on how I can force a re-enumeration without a Finder window currently being displayed?

I'm developing a macOS FileProvider extension which provides decrypted views of folders encrypted by our main application. If the user logs out of our app, the FileProvider re-enumerates the encrypted folder, replacing all the plain-text item names with their on-disk encrypted names, and any attempts to open an encrypted file will return encrypted garbage. This all works successfully for the most part. But if a given file has already been opened before the logout, the system still has its decrypted contents as a materialized item -- and while it won't open in its normal application, an "Open With" can still view the decrypted contents. Basically, is there a way to force the system to invalidate and remove the materialised copy of an item? At the moment I'm tracking all items in my working set, and not tracking materialised items separately... do I need to implement a separate set? Is it as simple as preserving the URL of any item whose contents I fetch, and then deleting that URL? Including the item in the set of re-enumerated items when the parent folder calls enumerateChanges doesn't seem to be enough to indicate that local contents are now invalid. How do I do that?

We've written a FileProvider plugin which displays the decrypted versions of encrypted files and folders stored in Dropbox. When removing encryption from a folder, we found one file was not properly decrypted -- it remained under its encrypted name (bPw4vCA6j5LOU,QuABQSsgmC.empfs). This turned out to be the folder's .DS_Store file. For some reason, a standard C++ iteration of the FileProvider folder did not include it. Is this normal behaviour for FileProvider? For the record, the problem doesn't occur if we iterate a non-FileProvider directory on the filesystem (e.g. "/Users/orextest3/Dropbox/EMPSecureFolders/EncryptedOrexTest3/"), only if we iterate the FileProvider mounted folder ("/Users/orextest3/Library/CloudStorage/EMPSecure-EMPSecureDropbox/EMPSecureFolders/EncryptedOrexTest3/"). And in some cases, the problem doesn't occur (I suspect a Finder setting of some sort). How can I ensure that these hidden files are included in an iteration? For the record, the C++ iterator loop was implemented using boost::filesystem: for (directory_iterator itr(source); itr!=directory_iterator(); ++itr)

My company has developed a desktop-Mac FileProvider extension which presents a user with shared encrypted folders; it's working well except for one issue. While we can handle moving an encrypted folder, there seems to be no way to detect that an encrypted folder has been copied or duplicated. Is there any equivalent to the Windows shell extension copy-hook handler, which can allow NSReplicatedFileProviderExtension (or some other portion of the system) to detect that a folder is being copied?