windows symlinks (aka junctions) mess up the is-outside-dir logic
osher opened this issue · comments
This is the culprit behind: istanbuljs/nyc#1381
I'll open a PR about it soon
Fun fact: using a subst
-based approach has the same effect:
Suppose you've got a dev tree that's hitting the Windows long filename issues in some spots (yeah, some git (GUI) tools still fail on the classic 260 limit 😢 ) and you 'fix' that by doing this in your root project/git repo path:
SUBST Z: .
and then switch to your regular bash+git+whatnot environment, addressing everything as a /z/bla/bla/blub/...
(bash) or Z:/bla/bla/blub/...
(CMD / PS) path.
The result: nyc
is dead in the water at 0 results a la your istanbuljs/nyc#1381.
Happens for any project here where your path are based off a SUBST
drive root.
^^^^^ Just in case someone gets the wrong idea here: let me emphasize:
Everything is under that new '/z/' root! That's the git repo itself, all the projects and related files. All the npm-install tools too! So this is emphatically NOT about jumping roots or symlinks half-way up the ladder anywhere. That Z:\...
example is like having a network drive mapping where all your shit is at.
Why'ld I do something 'crazy' like that? Simple. There's plenty on the dev box that's not considering code. Photoshop work, Book work, CAD work, etc. All sitting on a big fat honkin' SSD, vying for my attention. The software 'department' has its own place this way, with me saving some (path) typing and nice dedicated spot in the brain: coding is at
Z:
. Justnyc
not wanting to play along, for quite some time already. My go-around there is watching it at the CI instead when I feel the need. A bit sad, though.