This is a weird problem that I've just noticed happening, and trying to figure out why this is happening and how to "fix" the problem as I've already identified a way to work "around" the problem.

So we develop an application that is an Eclipse RCP, and is then signed and packaged into a DMG. The Eclipse framework used is supposed to write its data into a workspace, so running from a read-only device should not pose any problems.

Anyways to test our application, I mount the newly packaged DMG file, then locate our application and double click to launch. When the app launches, it launches with random versions of the internal components, as if the execution of the app is being copied to some sandbox on disk and then executed, the process which seems to be flawed and not actually replacing all the files in the .app directory as it should. I notice this because if I go click in our app to get the version number, and various module version numbers, they are different than what they should be.

Now to verify that I'm not crazy, I exit the app that was launched from the mounted DMG, and then copy the app to a new location on my local disk (so it's now on a read-write partition) and then launch. The app launches correctly with all the right bits (everything contains the right version number). This is the workaround.

This obviously seems like some bug in Gatekeeper potentially, as it should never use the same sandbox for an app across invocations, period.

So here are the questions after the long bit of context:

  1. Where does Gatekeeper sandbox launched applications? (assuming /private//tmp but I can't find anything)
  2. How do I force a reset the app sandbox used for running applications?
  3. If my suspicion is incorrect, and this is not Gatekeeper, what could it be? Why would /Volumes/ not have the actual files contained within image? (but clearly this isn't the case because I can copy the files from there to somewhere on the local disk and it works fine - leading me back to this is some special Gatekeeper-esque cache).

The condition appears to be reproducible on both Sierra and High Sierra.


You must log in to answer this question.

Browse other questions tagged .