Always use Junctions on Windows (fixes #22)

[theoy]

Windows supports two different types of "soft links", whereas in most MacOS/Linux-based operating systems, the common practice is to use symbolic links. LinkLocal was already using 'junction' links on Windows for versions older than Vista (e.g. XP). However, using a link type of 'symbolic link' on Windows for higher versions throws an error if you are using default Windows settings and are running as a normal user or an administrator that has not elevated into admin mode (e.g. UAC). So this change is of the flavour to just switch to using 'junction' links all the time on Windows, since unelevated/non-admin users are allowed to manage those under default Windows security settings.

Prior to this change, existing LinkLocal tests while on unelevated/non-admin would fail if using default Windows security settings. I verified this change makes it pass for non-admin/unelevated users in the default Windows security config at least on Windows 10 64-bit OS, NTFS file system (default FS type), 64-bit Node v0.12.9, NPM 3.5.2.

[theoy]

Boo, Travis pass failed. I believe it's because the configuration uses a moving target (e.g. NPM latest). Will see if I get some cycles to investigate sometime...

[timoxley]

@theoy 👍 thanks

[theoy]

So... got around to taking a peek. I don't think the Travis failure is related to the PR changes, but there are some interesting characteristics about Travis and the particular testcase. This does not fail when I repro it on MacOS with the same version of Node/io.js/NPM 😦

About the build: This Travis run is the first run for linklocal on Travis' new GCE infrastructure, instead of BlueBox. @timoxley - since you are the owner for the Travis config, can you engage with Travis and see if they can mark this repo to run on the old BlueBox environment while they investigate the GCE difference? The fact that it doesn't repo on my Mac dev box also suggests perhaps the CI environment is "special" either in its VM or container magic.

About the testcase: The testcase is failing during npm install of a package env that references [email protected] in two ways - by local file path -and- by .tgz. What's the expected behaviour in this case? In a normal dev environment, I'd tell my fellow devs to "don't do that!" 😄. It might be a bug in NPM itself in handling of this corner case, but without a repro environment it's hard for me to verify that / file that on the NPM project.

/cc @timoxley

From: https://blog.travis-ci.com/2015-11-27-moving-to-a-more-elastic-future

Our support and infrastructure teams will be giving primary focus to any regressions that may be experience during this migration process.

If you see problems with the new infrastructure's Precise image as we begin migrating, please open a GitHub issue with [precise-gce] in the subject or email [email protected] and include [precise-gce]in the email subject line.

[timoxley]

I've merged #27, which is basically the same. Apologies for the delay.