1

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.

Improve this question
3
  • 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

Reset to default
2

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.

Improve this answer

You must log in to answer this question.

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