Gatekeeper scans app before it finishes copying

Hi all,

I found an issue by chance where, when we copy an .app bundle (a large one), Gatekeeper can choose to try to scan the app before the file copying finishes (without the app having been launched). This of course fails, and then the app can't open because "it's damaged", even though spctl and codesign checks of the completed copied app come out fine. Then Gatekeeper remembers this setting forever, not rescanning the app.

I'm wondering if anyone else has seen this happen and if so, if there's a best practice for keeping Gatekeeper's hands off until the copy is done?

I imagine copying into a folder not named .app, then renaming it might work, or maybe saving the plist or main binary copy until last, although both require a more complex copy operation.

Maybe there's a more elegant way?

Thanks!

In what context are you copying the app? Programmatically? Or from the Finder? And if it’s programmatically, which API are you using?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn, thanks for looking into this! We are using C++ and the calls are:

  • std::filesystem::rename (where possible)
  • std::filesystem::copy (when necessary)

These are always called on individual files (not directories), but we also use this to create the parent dest directory if necessary:

  • std::filesystem::create_directories

After some more investigation this could be a problem only when we had an app in that place before. For example, we copy to /Applications/Test/MyApp.app on a new system, then we delete that folder and do it again later (but likely MyApp.app is now newer and different from the original one), and that's where I'm seeing this.

I haven't 100% confirmed the above but it seems to happen in that one case, but when I try on a new folder (eg /Applications/Test001/MyApp.app) so far it hasn't happened, so it might be a part of this and I wanted to mention it at least.

Thanks again for your time, it's very much appreciated!

If you’re working with partially constructed bundles — for example, you’re unpacking an archive containing an app — my general advice is that you do that work in a private location and then move the final item into place. For that last bit, use renamex_np to move the item into place atomically.

If you’re doing an update install and you need to keep bits from the old app, clonefile lets you do that without using any additional disk space.

I suspect that’ll be enough to get you past this. If not, lemme know and I’ll dig deeper.

Oh, and be careful of this: Updating Mac Software. Folks tend to learn about that the hard way )-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Gatekeeper scans app before it finishes copying
 
 
Q