Mac OS: App Translocation and Android Studio updates failure

Ashish on December 1, 2018

I installed Android Studio via homebrew “brew cask install android-studio” as a part of my automated Mac OS setup. Recently, Android Studio prompted me that an update is available. When I accepted to update, it failed with an error “Studio does not have write access to /private/var/folders/wt/rjv6_wcn4f97_2nth7fqftqh0000gn/T/AppTranslocation/19A80F28-865B-41FC-AA87-B8E43C826FCB/d/Android Studio.app/Contents. Please run it by a privileged user to update.” This error was confusing; I was running Android Studio as myself, a nonprivileged user and the same user owned this directory. Googling it a bit for AppTranslocation took me here.

From this point onward, the issue and the fix were relatively straightforward. Apple marked Android Studio as quarantine and hence was in a read-only directory. Quarantine status was confirmed by

$ xattr -l /Applications/Android\ Studio.app/
com.apple.quarantine: 00c1;5ad6b178;Chrome;9B843802-B7C1-4F48-BC68-09D8F81E6784

The fix was relatively simple as well

$ xattr -d -r -s com.apple.quarantine /Applications/Android\ Studio.app/

Update worked as expected after this.

Setting HOMEBREW_CASK_OPTS=–no-quarantine seems to enable this behavior for all the future installs.

Diagnosing Mac apps which won’t open (error -10810)

Ashish on December 21, 2017

Occasionally, my mac applications end up in a corrupt state where they won’t open. I recently encountered this with Deluge. The first step to diagnose is to open Terminal and open them in the terminal via

$ open -a deluge  # This name is same as the name of the app (minus the ".app" portion).
LSOpenURLsWithRole() failed for the application /usr/local/Caskroom/deluge/1.3.12/Deluge.app with error -10810.

Now, the error is more diagnosable but still cryptic. Deluge.app above is a directory and we can navigate to the binary located at Deluge.app/Contents/MacOS/Deluge and execute the actual binary to see a more actionable error

$ /usr/local/Caskroom/deluge/1.3.12/Deluge.app/Contents/MacOS/Deluge
Traceback (most recent call last):
  File "/usr/local/Caskroom/deluge/1.3.12/Deluge.app/Contents/MacOS/Deluge-bin", line 5, in <module>
    from pkg_resources import load_entry_point
  File "pkg_resources/__init__.pyc", line 37, in <module>
  File "email/parser.pyc", line 12, in <module>
  File "email/feedparser.pyc", line 27, in <module>
  File "email/message.pyc", line 16, in <module>
  File "email/charset.pyc", line 13, in <module>
  File "email/base64mime.pyc", line 40, in <module>
  File "email/utils.pyc", line 29, in <module>
  File "urllib.pyc", line 1414, in <module>

ImportError: dlopen(/usr/local/Caskroom/deluge/1.3.12/Deluge.app/Contents/Resources/lib/python/lib-dynload/_scproxy.so, 2): Symbol not found: _inflateValidate
  Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
  Expected in: /usr/local/Caskroom/deluge/1.3.12/Deluge.app/Contents/Resources/lib/libz.1.dylib
 in /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib

Now, this is something meaningful and Google search worthy. Googling for “Symbol not found: _inflateValidate” takes us to the most likely cause. In my case, uninstall followed by the reinstall of Deluge fixed it.

Mac OS X Primer (Part 2): Migrating from GNU/Linux to Mac for software engineers

Ashish on February 28, 2014

Booting process

  1. The bootloader loads the kernel stored in /mach_kernel. Tip: Use rEFIt as a bootloader for dual booting into GNU/Linux.
  2. Kernel launches the launchd process which is equivalent of init in GNU/Linux.
  3. launchd loads startup processes from several directories (/System/Library/LaunchAgents, /System/Library/LaunchDeamons, /Library/LaunchAgents, /Library/LaunchAgents and corresponding files in ~/Library directory)

Read More