search

volta-cli / volta

Volta: JS Toolchains as Code. ⚡
https://volta.sh
Other
10.95k stars 227 forks source link

Installation of Node Version failing on Windows 10 due to McAfee Virus Scanner collision #781

Closed dacarey closed 4 years ago

dacarey commented 4 years ago

Using Volta v0.8.3 on Windows 10, I've experienced intermittent but frequent issues with node installation failures. In my instance this appears due to a clash with the McAfee Virus Scanner. However I'd suspect it also apply to any real-time virus scanner being used on a Windows 10 installation as well.

Issue Manifestation

Run a Command to install a version of node. This example is for node 12 but it applies to other versions as well The screenshot below shows that this fails install-node12

Inspecting the error log shows the follow error

"C:\\Program Files\\Volta\\volta.exe" "install" "node@12"
Volta v0.8.3

Could not create environment for Node v12.18.2
at C:\Users\davecare\AppData\Local\Volta\tools\image\node\12.18.2

Please ensure you have correct permissions to the Volta directory.

Error cause: Access is denied. (os error 5)

Issue Analysis

I ran a trace with procmon and the cause can be seen in the access_denied message in the screen-show.
McAfee-Access-Denied-On-Rename

The fact that the trace also shows the McAfee Scanner scanning the directory being renamed suggest that it has locked the directory as this is the root cause of the issue.

Resolution Proposal

This is a common annoyance with real-time virus scanners and obviously a work-around is to stop the virus scanner. However on many corporate networks this isn't a viable option so my ideal would be a programmatic resolution, which is why I've raised this issue request

A good example of a similar scenario and a subsequent fix is document by the rust installer project in this issue https://github.com/rust-lang/rustup/issues/1870. It would be ideal if this pattern could be applied to volta to deal with this issue in the same way

charlespierce commented 4 years ago

Hi @dacarey, thanks for reporting this and for the detailed investigation! From the linked issue, it looks like rustup fixed this by adding retries with a progressively longer delay, to allow the virus scanner time to finish its operation. I think it would be straightforward to add the same behavior to our rename operations.