Hey all.
Trying to track down a bug on a client computer running OSX Sierra when using getAppPath(). Instead of returning the folder the app is in, it returns something like “/private/var/*/…” This throws permissions errors when trying to create new folders or log files. When looking at the command line args, argv[0] also return the same incorrect thing. Naturally, this works correctly on my computer running Sierra (10.12.4). Has anyone come across this? Both computers are admin users on 10.12.4
Thanks!
c
I just tested this on Sierra, and could not reproduce the issue. Where is the application located? Do you see any difference if you build the app on Sierra?
-Gabor
Does this at all have to do with that setting in Xcode that places all your build outputs in some common folder (which I usually recommend to turn off and build them into a relative xcode/build folder)?
@gabor_papp Thanks for checking it out. I can’t reproduce it either on my local machine. I just upgraded from El Capitan to Sierra, and that’s when it started. Both methods report properly on my local machine, no matter which folder it’s in. I was wondering if some OSX api changed, but it doesn’t seem to have.
@rich.e Not as far as I know. My build path is “./build” which builds into the xocde folder. Project was generated with Tinderbox. Targeting 10.8
Apparently boost::filesystem::current_path() returns “/”, I’m not sure if that’s the expected behavior, though it seems to be.
I think fs::current_path() returning “/” is expected on OSX. I built with cmake, though.
I’m of zero help here except to say that I came across the same thing yesterday. I have an app that caches data files in the assets directory that was crashing on boot because it was pointing to a similar location to what you mentioned, though i’m not using getAppPath directly rather the getAsset* family of functions (which likely use it behind the scenes)
I was also seeing this, but only when I ran the app on someone else’s machine. Running it on my dev machine consistently returned the expected path.
Just another data point–I didn’t end up hunting it down.
Update to this!
I believe it has to do with a new Sierra gatekeeper security feature. The thing to google for here is “App Translocation”. When someone tries to run an unsigned app from it’s original downloaded (or unzipped) folder, OSX mounts it into a temporary read-only disk image and executes it from there. This is why it will show up in a /private/var/*/ folder.
By manually moving it, it unsets a quarantine flag that let’s it then execute normally, and it will report it’s location correctly. It will also let you create folders/log files normally again. Moving with the command line does not unset this flag.
There is a lot more to it, but that should be enough to start help debugging this problem.
-c
2 Likes