Repository navigation
Possible Windows Node 6 regression with spawn and a substed drive #6500
Description
- Version:
v6.0.0 - Platform:
Windows 32 and 64 bit - Subsystem:
I've noticed a minor breaking change in either child_process.spawn or path.resolve (currently unclear), on Windows with Node 6. This issue appears to crop up when a Node script is execute from a SUBST'd path.
The production steps are tricky so I have created a reproduction in a repo that runs its tests in AppVeyor.
Activity
xzyfer commentedon May 1, 2016
This may be related to #5950.
saper commentedon May 1, 2016
Wow! I'm amazed.
saper commentedon May 1, 2016
@xzyfer can you rename the issue to "substed" ? (or reference "drive created by subst.exe") - only few MS-DOS die-hards like me remember, what a "substed drive" is.
[-]Possible Windows Node 6 regression with spawn and subset[/-][+]Possible Windows Node 6 regression with spawn and a substed drive[/+]xzyfer commentedon May 1, 2016
updated
Don't use subst for testing
Don't use subst for testing
Don't use subst for testing
Node 6 with AppVeyor: don't use subst for testing
Node 6 with AppVeyor: don't use subst for testing
Node 6 with AppVeyor: don't use subst for testing (#1514)
saper commentedon May 2, 2016
I have built node 7.0.0 (fa542eb) and the issue is still there. Reverting de1dc0a fixes the issue - npm test done one a substed drive passes.
xzyfer commentedon May 2, 2016
Nice find @saper
19 remaining items
jasnell commentedon May 2, 2016
See: #6537
dlongley commentedon May 3, 2016
@saper,
Could you just add an additional
requireto get around theisMainissue?dlongley commentedon May 3, 2016
I'd be +1 to removing the
isMainflag and never using realpath at all, by default. Not sure what the consequences of that would be, however.saper commentedon May 3, 2016
@dlongley node needs to use realpath not to try to load the same binary module twice. It's clunky, but that's how it currently works...
dlongley commentedon May 3, 2016
@saper,
Then we should only do
realpathon binary modules.kzc commentedon May 3, 2016
@saper Earlier in this thread I asked if the same test case worked with node 6.0.0 with a symlink instead of
SUBST. Just wanted to confirm that this is true or if I misinterpreted you. Just trying to determine the scope of the issue and whether symlinks are a workaround.saper commentedon May 3, 2016
I have not tried to reproduce it with symlinks before, I have only used
SUBST.EXE.But yesterday I wrote a test case for node to check for this issue and I have made the test case use
MKLINK.EXE(the symbolic linking on Windows) if it gets administrative privileges. The symptoms are the same (it does not matter if one usesSUBSTorMKLINK).evanlucas commentedon May 31, 2016
@xzyfer can you please try v6.2.0 and see if the problem still exists? Thanks!
Revert "Node 6 with AppVeyor: don't use subst for testing (#1514)"
Revert "Node 6 with AppVeyor: don't use subst for testing (#1514)"
Revert "Node 6 with AppVeyor: don't use subst for testing (#1514)"
xzyfer commentedon Jun 7, 2016
@evanlucas I can confirm this is fixed in Node v6.2.0 in both my reduced reproduction and in the larger node-sass ci.
evanlucas commentedon Jun 7, 2016
Glad to hear. Closing as this has been fixed. Thanks!!
Move back to using subst for testing