File permission error on Windows

[tfausak]

I decided to try out HLS via VSCode on Windows this morning. Mostly it works great, but every now and then this error pops up for me:

...: renameFile:renamePath:MoveFileEx "..." Just "..." permission denied (Access is denied.)

{
	"resource": "/E:/code/haskell-packages/rattletrap/src/lib/Rattletrap/Type/Attribute/RigidBodyState.hs",
	"owner": "Haskell (rattletrap)",
	"severity": 8,
	"message": "C:\\Users\\Taylor\\AppData\\Local\\ghcide\\main-6d3248553bb2b8d6eadeacc8ff134cc56b522e2e\\Rattletrap\\Type\\Attribute\\ext5A3: renameFile:renamePath:MoveFileEx \"\\\\\\\\?\\\\C:\\\\Users\\\\Taylor\\\\AppData\\\\Local\\\\ghcide\\\\main-6d3248553bb2b8d6eadeacc8ff134cc56b522e2e\\\\Rattletrap\\\\Type\\\\Attribute\\\\ext5A3\" Just \"\\\\\\\\?\\\\C:\\\\Users\\\\Taylor\\\\AppData\\\\Local\\\\ghcide\\\\main-6d3248553bb2b8d6eadeacc8ff134cc56b522e2e\\\\Rattletrap\\\\Type\\\\Attribute\\\\RigidBodyState.hie\": permission denied (Access is denied.)",
	"source": "compiler",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 2,
	"endColumn": 1
}

I'm using this with a pretty normal Stack project: one package, no custom setup, no Template Haskell.

Your environment

I don't have access to haskell-language-server or haskell-language-server-wrapper in my shell, although clearly the VSCode extension has it somewhere behind the scenes. How can I use the executable that the extension is using?

Which lsp-client do you use: Visual Studio Code 1.54.1

Describe your project (alternative: link to the project): https://github.com/tfausak/rattletrap

Contents of hie.yaml:

# Not included in the repo, but same as implicit cradle.
cradle:
  stack:
    - path: "./src/lib"
      component: "rattletrap:lib"

    - path: "./src/exe/Main.hs"
      component: "rattletrap:exe:rattletrap"

    - path: "./src/test"
      component: "rattletrap:test:test"

Steps to reproduce

Not sure exactly how to reproduce. I'm just making normal edits to files and eventually this happens. Maybe switching branches can cause the problem? I'm not sure.

Sorry, this isn't a very thorough bug report. I'll try to pin down exactly how to get this to happen.

[jneira]

Hi, thanks for the bug report, i am usually using hls on windows 10 (more times with cabal but also with stack) and i've not hit that one. My hls cache dir is in %APPDATA%\ghcide and i am logged as an administrator user.

I don't have access to haskell-language-server or haskell-language-server-wrapper in my shell, although clearly the VSCode extension has it somewhere behind the scenes. How can I use the executable that the extension is using?

The executable is downloaded in the vscode specific app data in my case: c:\Users\atrey\AppData\Roaming\Code\User\globalStorage\haskell.haskell\haskell-language-server-1.0.0-win32-8.8.4.exe --lsp -d

You can check the path (and other useful info to debug problems) in the log of the extension:

[tfausak]

Ah, thanks! Here's the output of haskell-language-server --probe-tools:

haskell-language-server version: 1.0.0.0 (GHC: 8.10.3) (PATH: C:\Users\Taylor\AppData\Roaming\Code\User\globalStorage\haskell.haskell\haskell-language-server-1.0.0-win32-8.10.3.exe) (GIT hash: 4cd1cf934638881e52b3eba9f70157a4b799c0e9)
Tool versions found on the $PATH
cabal:          Not found
stack:          2.5.1
ghc:            Not found

[tfausak]

Unfortunately I'm no closer to having a minimal way to reproduce this problem. It still happens semi-reliably for me, but I can't pin down exactly what's causing it to fail. Running stack build --file-watch in another terminal seems to be related? I can't tell if building with different options, like --test or --fast, is related or not.

[jneira]

Running stack build --file-watch in another terminal seems to be related?

mmm, definitely it could be, there is another issue about --file-watcher: #596
There we tried to workaround the issue setting an alternative .stack-work only for hls: #596 (comment)

[pepeiborra]

HLS has custom code to perform atomic file updates. Maybe it's not reliable in Windows.
If any contributor is interested, it might be worth looking for a suitable replacement in Hackage.

The code is at:

https://github.com/haskell/haskell-language-server/blob/master/ghcide/src/Development/IDE/Core/Compile.hs#L452-457

[theGhostJW]

Hi all,
I am now having the same issue. Also on windows. I have vague memories of this happening very occasionally before but now it's happening very frequently, say every 10 to 20 minutes.

I get errors such as this:

Error during compileC:\Users\thegh\AppData\Local\ghcide\main-05d0b1c44fabb6e0e05abce609bf6eb1b9f25f8c\Internal\extF1B4: renameFile:renamePath:MoveFileEx "\\\\?\\C:\\Users\\thegh\\AppData\\Local\\ghcide\\main-05d0b1c44fabb6e0e05abce609bf6eb1b9f25f8c\\Internal\\extF1B4" Just "\\\\?\\C:\\Users\\thegh\\AppData\\Local\\ghcide\\main-05d0b1c44fabb6e0e05abce609bf6eb1b9f25f8c\\Internal\\RunTimeLogging.hi.core": permission denied (Access is denied.)

After this HLS usually becomes unusable (i.e. no other errors shown, no code navigation), until it is restarted.

OS Name	Microsoft Windows 10 Pro
Version	10.0.19044 Build 19044

Seems to be triggered when I introduce a compilation error of some sort but other than that no particular pattern stands out.

I have tried:

1. deleting the contents of the ghcide folder
2. excluding the ghcide from windows virus scanning
3. uninstalling and reinstalling the HLS plugin
4. reinstalling stack via ghc-up
   none of which worked.

One thing I have noticed is there are multiple instances of hls runnning:

Is this meant to happen?

Full HLS Log

[HLSLog.txt](https://github.com/haskell/haskell-language-server/files/9898443/HLSLog.txt

---

OK seems to have been caused by contention between ghcid and HLS.
Solved by more or less applying the same fix as recommended above.

The fix was:
1. create an alternative stack.hls.yaml by duplicating stack.yaml
2. update hie.yaml with a new line pointing to the new stack file:

cradle:
  stack:
    stackYaml: "./stack.hls.yaml"
    components:
     - path: "./src"
       component: "pyrethrum:lib"
     - path: "./test"
       component: "pyrethrum:test:pyrethrum-test"

Now the error has stopped occurring.

[theGhostJW]

Unfortunately the above comment was premature and the issue has reoccurred. This is intermittent and does not necessarily need ghcid running for the error to occur. Will try to get more specifics in coming weeks.

[theGhostJW]

Hello,
here are some logs.
using

VSCode
Windows 10
Stack

Tool versions found on the $PATH
cabal:          3.6.2.0
stack:          2.9.1
ghc:            9.0.1

Tool versions in your project   
ghc:            9.0.2

hie.yaml

cradle:
  stack:
    stackYaml: "./stack.yaml"
    components:
     - path: "./src"
       component: "pyrethrum:lib"
    #  - path: "./test"
    #    component: "pyrethrum:test:pyrethrum-test"

Repo - (stack based project)

https://github.com/theGhostJW/pyrethrum/tree/concurrency2
https://github.com/theGhostJW/pyrethrum/releases/tag/access-denied

The project is very much a work in progress aka. a mess. I have only been editing:

test\SuiteRuntimeTest.hs 
...and occasionally
src\Internal\SuiteRuntime.hs

The error occurs whether I'm running ghcid in parallel or not but I suspect is more frequent when ghcid is running:

ghcid --command 'stack ghci --test' --allow-eval --clear --no-height-limit '-o ghcid.log' 

A typical error is:

Error during compile C:\Users\thegh\AppData\Local\ghcide\main-c70615d89a7a639097b386336e61e4aed219e86e\Internal\ext9C9B: renameFile:renamePath:MoveFileEx "\\\\?\\C:\\Users\\thegh\\AppData\\Local\\ghcide\\main-c70615d89a7a639097b386336e61e4aed219e86e\\Internal\\ext9C9B" Just "\\\\?\\C:\\Users\\thegh\\AppData\\Local\\ghcide\\main-c70615d89a7a639097b386336e61e4aed219e86e\\Internal\\SuiteRuntime.hi.core": permission denied (Access is denied.)

When the error occurs I need to restart VSCode, just restarting hls from within VSCode does not fix it.

One thing I can say for certain is that when error does occur it is after a type error has been introduced in one of the source files listed above.

Detailed logs attached

accessDenied-logs.zip

[theGhostJW]

possibly related to: haskell/directory#109 ?

[soulomoon]

Indeed, #4276