Stack: When updating, "removeDirectoryRecursive: permission denied (Access is denied.)" Windows 7

[wapxmas]

This happens in any directory:

D:\>stack -v update
Version 1.1.2, Git revision c6dac65e3174dea79df54ce6d56f3e98bc060ecc (3647 commits) x86_64 hpack-0.14.0
2016-08-02 15:59:34.979211: [debug] Checking for project config at: D:\stack.yaml @(stack_9kewhubnl5WIl89fhd1ea2:Stack.Config src/Stack\Config.hs:811:9)
2016-08-02 15:59:34.980211: [debug] No project config file found, using defaults. @(stack_9kewhubnl5WIl89fhd1ea2:Stack.Config src/Stack\Config.hs:833:13)
2016-08-02 15:59:34.984212: [debug] Creating process: D:\usr\git\bin\git.exe fetch --tags --depth=1 @(stack_9kewhubnl5WIl89fhd1ea2:System.Process.Run src/System\Process\Run.hs:102:5)
Fetching package index ...fatal: Not a git repository (or any of the parent directories): .git
2016-08-02 15:59:35.011213: [warn] Process exited with ExitFailure 128: D:\usr\git\bin\git.exe fetch --tags --depth=1 @(stack_9kewhubnl5WIl89fhd1ea2:Stack.PackageIndex src/Stack\PackageIndex.hs:262:17)
Failed to fetch package index, retrying.
removeDirectoryRecursive: permission denied (Отказано в доступе.)

[wapxmas]

Solved when I remove \stack\indices\Hackage\git-update\all-cabal-hashes.git

[wapxmas]

Problem is that some files in .git marked as "read only" and removeFile within removeDirectoryRecursive cannot delete these files on Windows.
Main problem is in the Win32.deleteFile as MSDN says "_If the file is a read-only file, the function fails with ERROR_ACCESS_DENIED_." It seems to be removeDirectoryRecursive in the directory package, rewritten for Windows.

[Blaisorblade]

We just need to start using the new removePathForcibly correctly to fix this. Lack the time, anybody up for it?

[dotdat]

It looks like this may still be an issue. If you're open to pull requests, I could take a stab at it.

[mgsloan]

@dotdat Oh yeah certainly, contributions are definitely appreciated!

[cblp]

The same problem on the very initial stack setup

...
Everything is Ok

Folders: 546
Files: 12804
Size:       155115162
Compressed: 165253120
C:\Users\Syrovetsky\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512-tmp6924\msys64\: renamePath:MoveFileEx "C:\\Users\\Syrovetsky\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20150512-tmp6924\\msys64\\" "C:\\Users\\Syrovetsky\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20150512\\": permission denied (Access is denied.)

[mpilgrem]

A colleague on Windows 7 was experiencing the permission denied errors with stack upgrade --git, following a clean install of stack 1.7.1. I wondered if this issue still needed a pull request?

In that regard, am I correct to understand @Blaisorblade to suggest that (from module System.Directory) removeDirectoryRecursive :: FilePath -> IO () needs to be replaced by removePathForcibly :: FilePath -> IO ()?

If so, removeDirectoryRecursive is used in three places: src\Setup.hs (line 1420), test\integration\IntegrationSpec.hs (line 79) and test\integration\tests\cabal-solver\Main.hs (line 13).

[Blaisorblade]

@mpilgrem That's the basic idea, but it's not fully accurate. Stack also calls removeDirRecur (in many files) which also has the same problem because it calls removeDirectoryRecursive.

I'm sketching a PR for this, I just need to get it to a compiling state.

[Blaisorblade]

@mpilgrem I'm testing that PR a bit on Mac, do you think you could test it on Windows?

[stefjoosten]

I seem to have the same problem on a MacBook.

Is this the same issue? Any ideas?

[Blaisorblade]

@stefjoosten The workaround is to remove that folder by yourself. To figure out how to fix it, it’d be good to not remove it, and instead to look at the permissions, ACL, and flags; but I’m not sure if this is something that we can/should fix easily.

On Mac, I’ve seen cases where files could only be removed using OSX-specific APIs (iirc, calling chflags). Those won’t be created by Stack, but in other ways... (Might have been by interacting with Time Machine backups by hand?).

In general, if the problem arises systematically and somebody can write a good fix, it’d be good to merge it, but I guess we cannot recover from all possible corruptions of Stack data.