Stack: Permission denied when run stack setup on Windows 10

[Yury-Zakharov]

OS: Windows 10 x64
stack version: Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commits) x86_64
GHC version: Not installed
Anamnesis:
after installing stack 1.0.4 run "stack new ..."
run "stack setup" stack downloads and extracts ghc files but then terminates with the following output:

C:\Users\username\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3-tmp9724\ghc-7.10.3: MoveFileEx "C:\Users\username\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3-tmp9724\ghc-7.10.3\" "C:\Users\username\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\": permission denied (Access is denied.)

[mgsloan]

Strange. And you have permission to write to that directory (C:\Users\username\AppData\Local\Programs\stack\x86_64-windows\)?

[mgsloan]

This comment may be relevant: https://github.com/commercialhaskell/stack/issues/216#issuecomment-110316227

Perhaps the error message is really poor and the issue is really that the dir C:\Users\username\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3 already exists?

[Yury-Zakharov]

Strange. And you have permission to write to that directory

(C:\Users\username\AppData\Local\Programs\stack\x86_64-windows)?

Yes, I do have permission. Also I run a shell (cmd.exe) as administrator.

Perhaps the error message is really poor and the issue is really that the dir

C:\Users\username\AppData\Local\Programs\stack\x86_64-windowsghc-7.10.3 already exists?

No, there is no such directory. C:\Users\username\AppData\Local\Programs\stack\x86_64-windows\ does not contain any subdirectories at all.
GHC is not installed anywhere on this machine.

[mgsloan]

Unfortunately I have no idea, and I don't know much about windows. Please update this ticket if you find a solution

[louy2]

Thanks msgloan for pointing, I indeed had the same issue. I ended up using an Admin cmd to do stack setup.

[Yury-Zakharov]

Found workaround:
After unsuccessful "stack setup" there are some files left in a C:\Users\username\AppData\Local\Programs\stack\x86_64-windows directory, one looks especially promising :) - ghc-7.10.3.tar.xz
Extracting its content created a directory "ghc-7.10.3" with ghc things inside.
I've tried to run "stack build" in my project directory but it would not work of course but, I run "stack setup" and this time it done the job - ghc installed and can be used.
I would not agree this resolve the issue as such, but can be used as a quick and dirty workaround.
Thanks everyone for patience.

[louy2]

@Yury-Zakharov
Why did it not work on my side? QAQ
I tried the same, extracting the binaries into folder ghc-7.10.3, only to have it removed entirely by stack setup.

[Yury-Zakharov]

@louy2
To be honest - I don't know. I am not a developer of the stack utility, just trying to use it on my Windows box and found workaround that works in my case. Hopefully this workaround may help developers to understand what went wrong...

[mgsloan]

@louy2 Perhaps you have an old stack version?

[louy2]

@mgsloan

stack --version
Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commits) x86_64

[eriknstevenson]

As is pointed out in this cabal issue, the error could be caused by renameDirectory failing on Windows if the new path already exists.

Curiously, the only place this function is used is in Fetch.hs as part of a work-around solution for #157.

My naive approach to solve this would be to delete the directory at newDist if it exists. Admittedly I am in a bit over my head at this point, and am unsure if newDist could possibly already contain other needed files.

when exists $ do
  when (newDist == oldDist) $ D.removeDirectoryRecursive newDist

  -- Previously used takeDirectory, but that got confused
  -- by trailing slashes, see:
  -- https://github.com/commercialhaskell/stack/issues/216
  --
  -- Instead, use Path which is a bit more resilient
  ensureDir . parent =<< parseAbsDir newDist
  D.renameDirectory oldDist newDist

[mgsloan]

Stack mostly uses path-io rather than directly using the directory functions. Search Stack.Setup for renameDirectory. I don't see anything wrong with the usages - the destination directories are being removed.

[eriknstevenson]

Ah thanks for pointing that out I somehow missed it.

[Yury-Zakharov]

@narrative, @mgsloan - In my case (see the original posting) it behaves in just the opposite manner: when there is no destination directory, it fails, when the directory already exists it successfully rewrites it (deletes and creates a new one). Weird behavior for me...

[mgsloan]

Strange!

@mrkkrp Any possibility this has anything to do with path-io related changes?

[mrkkrp]

Well, path-io wrappers are really thin for most operations and there has been no change to this functionality from the very beginning (most changes were about coping of directories and new tests). Note that in this snippet original functions from directory are used: removeDirectoryRecursive and renameDirectory, so I'm not sure this has anything to do with path-io.

[mgsloan]

@mrkkrp Cool thanks for the info! Since this issue is quite puzzling, I'm just considering all possibilities.

[bananu7]

Just wanted to say that I've also hit the problem (Windows 8.1 x64), and indeed the workaround of removing ghc-7.10.3.tar.xz made it work.

[bananu7]

Funny enough, the second time (different machine, same OS) I had to manually create the ghc-7.10.3 folder, so that it could remove it and only then it properly extracted.

:game_die:

[jankatins]

Ok, I can't get it to work:

• I have write rights to C:\Users\jschulz\AppData\Local\Programs\stack\i386-windows
• If I run stack setup, it downloads ghc-7.10.3.tar.xz and tries to extract it, ending in the above error about not having permissions to move the files into the right location
• If I try to manually unpack the tar.gz and move it into the right location C:\\Users\\jschulz\\AppData\\Local\\Programs\\stack\\i386-windows\\ghc-7.10.3\\, this is possible, but stack build does not find it
• if I run stack setup again, the extracted files/ whole dir is removed and the cycle starts again

Could it be that the move is too shortly after the 7z call and the old dir is still locked?

[mdunsmuir]

I am also seeing this issue on Windows 7. None of the suggested workarounds in this thread (manually unzipping the archive, running stack setup with the ghc-7.10.3 directory already present, etc.) are working for me.

update: I seem to have gotten around this by using the 64 bit version (was using 32 before), which caused (?) the GHC install to succeed. However, I got the same error with the msys2 install which happens next. I disabled that, and stack setup --skip-msys exited happily, and stack build works.

I only vaguely know what msys2 is, but this is a bit of a throwaway application so I'm not really inclined to dig deeper as long as everything works (my project builds, but beyond that there may be issues). I will report back if I find anything more that might be of general interest.

[mpilgrem]

I had the same 'Access is denied' problem on Windows 10 Pro 64-bit with ghc-8.0.1, when stack setup had worked previously with ghc-7.10.3 (on both occassions, working in Command Prompt with Administrator privileges). My work around the problem was this:

1. I changed directory to the 'install location' directory that is identified by the stack path --programs command.
2. Archive file ghc-8.0.1.tar.xz had been left in that folder. I used 7z (which was also in that folder) twice to extract it (to create new folder ghc-8.0.1).

7z x ghc-8.0.1.tar.xz
7z x ghc-8.0.1.tar

1. I created a ghc-8.0.1.installed file in that folder by making a copy of the existing ghc-7.10.3.installed file that was in that folder.

copy ghc-7.10.3.installed ghc-8.0.1.installed

The .installed files appear to be 9 byte files containing installed in UTF-8 encoding.

1. I deleted the (large) ghc-8.0.1.tar file, to clean up.

[addy]

I was still having this issue, so I downloaded ghc standalone. I extracted out the ghc-7.10,3 folder and then added the bin folder inside of that to my PATH. If done correctly, you should be able to use ghci outside of stack. Stack will default to a ghc if it is already available on the path, so you won't have to deal with permission issues at all.

[sarvex]

I faced the same issue; first with ghc and then with mingw.

Workaround that helped me :

• "create a new folder of the expected name" stack will rename to tmp and then back to normal.

[brodyberg]

Definitely doesn't repro w/ 32bit os.

[brodyberg]

I don't see a repro with stack new repro on a fresh install of Windows 10 build 10.0.14393 x64. Are there more repro steps?

[dnadales]

I'm having this problem when cloning an existing stack project. I don't know if that makes any difference. The command that fails is:

stack --install-ghc build

And I'm running this as admin.

[dnadales]

In my case I ran

stack --install-ghc build

first as a non-admin user. After deleting the tar file and re-running the command as admin I managed to install ghc.

[brodyberg]

There's a chance there may have been virus scanning in the directory. Cloning a repo will bring down a lot of files the scanner will find interesting unless you create a scanning exclusion.

[algida]

I have same permission issue when I try stack setup on Win10 x64.
(stack : Version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 x86_64 hpack-0.15.0)
It seams that current directory is inside folder in moment when it tries move it to another location) .

Is there any chance that it will work or is it better to setup Linux virtual. This issue is open for months.

[SOLVED]
I tried to disable Avira antivirus and all seams ok. That is wierd :-(

[tdnguyen714]

I was having this exact same problem and indeed, after turning off antivirus, stack setup works.

[sgraf812]

Definitely seems to be the antivirus.

[mgsloan]

Seems like there isn't anything to fix in stack here, and the conversation has gotten long . Closing as a support ticket, where the suggested resolutions include:

• Disabling antivirus (Avira, maybe others)

• Manually unpacking downloaded ghc - https://github.com/commercialhaskell/stack/issues/1917#issuecomment-222303266

Please open additional tickets for similar issues.

[ajuc]

I have the same problem, but only if I do stack build the second time (after changing code in any way). The first time after booting windows it works no problem, but later it doesn't.

It might be related to some windows permissions problems, because I have the same problem (permission denied) with Steam actualization of some games on that machine.

I also wonder if it's maybe related to windows 260 char path limtation, but I disabled that in registry and it didn't helped.

[brodyberg]

No, this is due to anti-virus as indicated previously.

[dmvianna]

I think I figured it out. I wasn't able to install GHC-8.0.1 after many stack setup runs. Then I just went to ~/AppData/Local/Programs/stack/x86_64-windows (which I found running stack path --ghc-paths outside of my project) and created the ghc-8.0.1/ directory. The following stack setup run did it.

[Yechoh]

I thought I had the problem, when running 'stack install' to generate some exes. But I still had the exes running, which gave a 'permission denied'. Closing them solved the problem.

[jwilliamson1]

I don't know if this is related to anti-virus or not, but what worked for me was deleting everything in %localappdata%\Programs\stack\x86_64-windows, then running stack setup again. If you have other versions of GHC in that folder then maybe move them somewhere else before deleting and back after.

[mvoidex]

Still having this issue.
There's no more .installed files, and i have no rights to disable antivirus. I'm stuck

[winter3angle]

I was having this exact same problem and indeed, after turning off antivirus, stack setup works.

Confirmed exact same behavior with Kaspersky Internet Security 20.0.14.1085(i). Disabling it for a while does the trick

[rsousacode]

I eccounter this error in a non-admin user, I had to extract manually the contents move to the expected folder (ghc-xxx and msys2-xxx) and run again stack. It's bad that I had to run multiple times stack setup, since it doesn't work properly at first. Deactivating Kaspersky 20 wasn't a option.

[zetaraku]

By manually removing the destination folder indicated by the error message, the stack setup command now works successfully for me. :)

[renngar]

Confirmed exact same behavior with Kaspersky Internet Security 20.0.14.1085(i). Disabling it for a while does the trick

You don't have to disable it. Adding an Exclusion for C:\User\<user>\AppData\Local\Programs\stack\ worked for Kaspersky Security Cloud.