New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NTFS junctions #79
Comments
Another point in favour of junctions: they are used by |
I'll consider it for the next version (which I'm working on as time allows). I almost did this for the first releases, but I had a number of requests for cross-drive support, so I'm not sure if this is an acceptable limitation... but the idea of keeping it behind a flag is viable. |
symbolic links are more flexible in the targets they support. see mklink. |
some of are using workin machines though that restrict certain admin actions such as mklink |
@edclement Not good for Dev PCs at all. Fight for freedom :) |
@edclement - there is literally nothing that can be done if mklink isn't allowed by enterprise policy. I believe this would also affect npm. The entire premise of this project is based on the use of linked directories. |
@coreybutler - I use |
@edclement, @coreybutler I'm reasonably sure that
This is true, but I would be surprised if the In my original issue description, I suggested toggling use of junction points with a flag, but I now think it should be the default option whenever the source & target drive letters are the same. But I'd be happy either way 😄 |
It does look like npm is using junctions for links, and it also looks like npm suffers from the same issue nvm4w would if it were installed on a separate partition. I still like the idea of toggling, and I like @jgoz's follow up comment about checking the drive letters. I'm 99% sure I'll implement at least a toggle/flag if I can't find a better alternative to mklink. |
modified elevate.cmd as a quick fix if you really need it
|
I'm reposting this here since I inadvertantly merged it into the wiki some time ago. Written by Burt Harris: Elevator pitch for Junction PointsOn Windows, a NTFS junction point can generally be created and deleted without any special privileges; junction points were created as a safer alternative to directory symlinks. If nvm-windows switched its implementation to use NTFS junction points, it could would be simpler, more usable, and present lower security risks. The demoUsing NTFS junctions is really simple, this should give you the idea:
As can be seen below, a junction point presents a much more understandable directory listing
Completing the pictureIdeally, one user on a machine installing or removing nvm-windows or Node.js versions using the tool shouldn't effect any other user's experience on the same machine. For this reason, installing junctions in C:\Program Files would still require and administrator. But per-user tools can generally be installed under the path in the APPDATA environment variable, and that's where the per-user nvm junction point should be located. Similarly user-specific NVM_HOME, NVM_SYMLINK and PATH environment variables are preferable to machine-wide ones. |
Are you sure about that? MS docs and examples read different to me:
The one not permitted example using
|
@veda-tschoening Not being able to use a mapped network drive is a major problem for enterprise users who rely on a common SAN/NAS solution. Over 20% (~1.4M developers) of the user base would be negatively affected by this. That's why it has stalled. NTFS junctions will not be coming to NVM4W. Runtime, the successor we're working on, is planning to support a few different options though. |
Would have been great if this could've been added years ago, stumbled across this facing the issue of requiring admin privileges to |
Would it be feasible to add support for using NTFS junctions rather than
mklink
for swapping out the in-use version of node?Junctions are great because they do not require elevated permissions, which would allow
nvm-windows
to be used on (effectively) headless machines, such as build agents. The disadvantage is that they cannot be created across drive letters, but this is an acceptable limitation.Maybe this could be implemented as a configuration flag and disabled by default. Thoughts on that?
The text was updated successfully, but these errors were encountered: