OS X Data loss workaround

gistfile1.md

The code below demonstrates a solution that is immune to the Data loss on OS X Broccoli issue and demonstrated in this gist

Save the following code to linktest.js:

var fs = require('fs');

// setup structure
fs.mkdirSync(process.cwd() + '/vendor');
fs.mkdirSync(process.cwd() + '/vendor/my_lib');
fs.writeFileSync(process.cwd() + '/vendor/my_lib/foo.js', '// better than nothing');

// setup temp working directory
fs.mkdirSync(process.cwd() + '/.tmp');
fs.mkdirSync(process.cwd() + '/.tmp/.tmp');
fs.symlinkSync(process.cwd() + '/.tmp/.tmp', '.tmp2');
fs.linkSync(process.cwd() + '/.tmp2', 'tmp');

// change to working directory
process.chdir(process.cwd() + '/tmp');

// this should fail
fs.symlinkSync(process.cwd() + '/../vendor/my_lib', 'my_symlinked_lib');
fs.linkSync('my_symlinked_lib', 'my_hardlinked_lib');

And run on OS X as follows:

mkdir linktest && cp linktest.js linktest && cd linktest && node linktest.js

You will notice you cannot create a hardlink to a directory when you are already inside a hardlinked directory and instead fails with an error similar to:

 … fs.js:753
  return binding.link(pathModule._makeLong(srcpath),
                 ^
Error: EPERM, operation not permitted 'my_hardlinked_lib'
    at Object.fs.linkSync (fs.js:753:18)
    at Object.<anonymous> (/Users/andrew/scratch/link_test/linktest.js:19:4)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:906:3