Closed Andy65 closed 7 years ago
Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!
Here is what to expect next, and if anyone wants to comment, keep these things in mind.
I also see this problem with elm 0.18.0
Ditto (elm 0.18.0; windows 10 Pro).
One workaround is to simply re-run the install until it works. I think the error is in fact a problem in creating parent directories. Each run of the installer manages to create another folder in the path until it can finally install everything successfully.
This hypothesis is supported by another workaround, which is to move the folder by hand...
e.g. if the message is "elm-package.exe: elm-lang-virtual-dom-a4c0afe: MoveFileEx "elm-lang-virtual-dom-a4c0afe" "elm-lang\virtual-dom\2.0.2": permission denied (Access is denied.)"
then you can simply move "elm-stuff/packages/elm-lang-virtual-dom-a4c0afe" to "elm-stuff/packages/elm-lang/virtual-dom/2.0.2", making sure all the interim folders (elm-lang/virtual-dom) exist. I happen to use MobaXterm, hence the forward slashes. If you're on a raw Windows box, use FileExplorer or change to backslashes to suit. Re-run the install command to check that it completes successfully (there should be no harm in doing this)
NB: since you can move the folder by hand, it's clearly not a permissions problem. It might be a "mkdir -p" problem, though - if a parent folder doesn't already exist, perhaps? The fact that creating the folder by hand or re-running the install command works (eventually) suggests this is in fact the case.
EDIT: Just to clarify, I am not running McAfee, though I do have Windows Defender enabled.
I've resolved the exact error the OP describes by disabling McAfee live scan. It does not have to be disabled for npm, pip, gem or similar programs from working properly, so it does seem to be specific to elm.
The issue https://github.com/commercialhaskell/stack/issues/1917 mentions that the issue may be that renameDirectory
can fail on Windows if the new directory already exists.
In the 0.18 implementation, we use that function when unpacking downloads here. In the upcoming implementation, I figured out how to avoid the directory move when unpacking the .zip files here. So I expect this to be resolved in 0.19, but I am not sure.
I will close for now, and we can open a new issue if it persists after that.
I am running elm package install in a new folder and get the attached output:
Windows 10 Google Chrome 52.0.2743.116 m Elm 0.17.1
A previous closed version of this issue referred to iDrive but I do not have this installed - I do have McAfee which may be doing something similar but I do not have admin access to be able to disable it.