With bash as my shell, a simple way to demonstrate my question is this:

mkdir -p foo.app/Contents
cd foo.app/Contents
echo -n 'AEgxFXTC' > PkgInfo
ln PkgInfo f

The ln will fail with ln: f: Operation not permitted

I am on 10.10.5 with a Mac OS Extended (Journaled, Encrypted) file system.

There seems to be some magic squirreled away in the file system for files named PkgInfo inside a directory named Contents. The contents of the file does not seem to matter.

What is the magic specifically? Are there other magic names besides PkgInfo? Why is it special? etc.

  • Hmm... add the absolute path to your hard link. ` ln /path/to/foo.app/Contents/PkgInfo f``. f is in the current working directory.
    – fd0
    Aug 31, 2015 at 17:53
  • I originally discovered this with absolute paths but I tried it again and same result. Both paths can be relative or absolute with the same results. Contents must be within a directory with .app suffix it appears and PkgInfo must be within Contents to get this behavior.
    – pedz
    Aug 31, 2015 at 18:09
  • Apparently Resources/*.lproj files affected too. mjtsai.com/blog/2016/07/22/…
    – clacke
    Jul 3, 2017 at 14:25

1 Answer 1


This is an undocumented security "feature" of macOS. See https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/CB0zClGfh3c

This turns out to be an issue specific to *.app/Contents/PkgInfo and .app/Contents/Resources/.lproj files. OS X does not want to permit the creation of a hard link between one of these items in an application bundle to another file in a non-application-bundle folder. I was unable to find an explanation for this behavior in Apple's documentation, nor in the source code for HFS or the OS X kernel.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .