Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doesn't work on Windows #216

Closed
ndmitchell opened this issue Jun 9, 2015 · 26 comments
Closed

Doesn't work on Windows #216

ndmitchell opened this issue Jun 9, 2015 · 26 comments
Assignees
Labels
Milestone

Comments

@ndmitchell
Copy link
Contributor

@ndmitchell ndmitchell commented Jun 9, 2015

C:\Neil\hlint>stack build
Downloading lts-2.13 build plan ...
Downloaded lts-2.13 build plan.
Populating index cache, may take a moment ...
Updating package index hackage.haskell.org ...
Cloning package index ...
Done populating index cache.
Checking against build plan lts-2.13
Writing default config file to: C:\Neil\hlint\stack.yaml
Downloading ghc-7.8.4 ...
Downloaded ghc-7.8.4.
InvalidUrlException "7z" "Invalid URL"

C:\Neil\hlint>ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3

So it tries to download GHC 7.8.4, even though I have 7.8.3 installed (which seems like a bug). It also fails to do that.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

What does stack --version say?

@ndmitchell
Copy link
Contributor Author

@ndmitchell ndmitchell commented Jun 9, 2015

C:\Neil\hlint>stack --version
Version 0.0.0, Git revision 6bf1ba3a7a3fdf92fa4af2ccb148ee2004dd607a (dirty)

I'm using the version from https://github.com/commercialhaskell/stack/wiki/Downloads#windows

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

Ouch, OK, testing now

@snoyberg snoyberg added this to the Second release milestone Jun 9, 2015
@snoyberg snoyberg self-assigned this Jun 9, 2015
@snoyberg snoyberg added the type: bug label Jun 9, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

Downloading 7.8.4 is intentional: it requires at least the tested version of GHC from the snapshot, and that LTS snapshot was built with 7.8.4. I haven't reproed that problem yet, still trying

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

OK, reproed, now fixing

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

Found the bug, slipped in after my testing:

d9f2f66#diff-4968f87e674615592e572f2ec593e5b0L550

snoyberg added a commit that referenced this issue Jun 9, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

OK, pushed a fix for it. I'm just rebuilding everything locally and then I'll upload a new executable.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

@ndmitchell I've uploaded a new binary, can you confirm that this works? Everything is running correctly for me.

@snoyberg snoyberg assigned ndmitchell and unassigned snoyberg Jun 9, 2015
@snoyberg snoyberg modified the milestones: Third release, Second release Jun 9, 2015
@ndmitchell
Copy link
Contributor Author

@ndmitchell ndmitchell commented Jun 9, 2015

Still doesn't work:

C:\Users\NDMIT_~1\AppData\Local\Temp\stack2856\happy-1.19.5\dist: MoveFileEx "C:
\\Users\\NDMIT_~1\\AppData\\Local\\Temp\\stack2856\\happy-1.19.5\\dist" "C:\\Use
rs\\NDMIT_~1\\AppData\\Local\\Temp\\stack2856\\happy-1.19.5\\dist-stack\\i386-wi
ndows\\Cabal-1.18.1.5\\": permission denied (Access is denied.)
@ndmitchell
Copy link
Contributor Author

@ndmitchell ndmitchell commented Jun 9, 2015

In particular, C:\\Users\\NDMIT_~1\\AppData\\Local\\Temp\stack2856 doesn't exist, but I don't know if that was because stack cleaned it up on exception.

@ndmitchell
Copy link
Contributor Author

@ndmitchell ndmitchell commented Jun 9, 2015

I confirm this happens repeatably.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

Different issue: this only applies to happy, because of the terrible workaround it requires to build. The dist directory needs to get renamed. Testing if this is still Windows-only before fixing.

@ndmitchell
Copy link
Contributor Author

@ndmitchell ndmitchell commented Jun 9, 2015

Why is it building happy anyway? I have it installed and on my PATH. Or does it require happy build with its GHC?

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

It builds the version of happy in the snapshot to be on the safe side. It's also to do with the fact that build-tools fields in .cabal files are undefined, and may refer to either an executable or a package, so the fact that you have happy.exe available doesn't prove that you have the right build tool... it's quite a mess actually. Anyway, there's an easy fix I'll push immediately, and then a better one to be worked out.

@ndmitchell
Copy link
Contributor Author

@ndmitchell ndmitchell commented Jun 9, 2015

It's a mess, which is why I want to use stack in the first place :)

snoyberg added a commit that referenced this issue Jun 9, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

Hah, true. OK, can you pull master and see if that lets you build hlint? It seems to be working for me now.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

And I'm wondering if this should be opened as a bug against directory, since the behavior on Windows and Linux is difference for renameDirectory. That might just be an inherent OS difference though.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

Turns out that this is a documented difference in renameDirectory:

On Win32 platforms, renameDirectory fails if the new directory already exists.

Anyway, the fix in place is the correct one (use Path.parent which is aware of the trailing-slash issue). takeDirectory was following it's documented behavior, which happens to not work well with Path's way of doing directories.

@ndmitchell
Copy link
Contributor Author

@ndmitchell ndmitchell commented Jun 9, 2015

OK, with the git version it all worked.

@ndmitchell ndmitchell closed this Jun 9, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

W00t. Thanks again for catching these, I'll add "build hlint" to the release checklist, and make sure that there aren't more commits added after we've gone through the checklist next time.

@Timp-ELS
Copy link

@Timp-ELS Timp-ELS commented Oct 18, 2018

Hi, this seems to have resurfaced:

Everything is Ok

Folders: 520
Files: 11779
Size: 2080675659
Compressed: 2090035200
C:\Users\pizeyt\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3-tmp23292\ghc-8.4.3: renamePath:MoveFileEx "C:\Users\pizeyt\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3-tmp23292\ghc-8.4.3\" "C:\Users\pizeyt\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.3\": permission denied (Access is denied.)

@dbaynard
Copy link
Contributor

@dbaynard dbaynard commented Oct 18, 2018

@Timp-ELS Which stack version?

@Aarskin
Copy link

@Aarskin Aarskin commented Jan 4, 2019

@dbaynard I'm seeing this with Stack v.1.9.1 (Windows 10 Enterprise, Version 1709, Build 16299.726)

stack --version
Version 1.9.1, Git revision f9d0042 (6168 commits) x86_64 hpack-0.31.0

@dbaynard
Copy link
Contributor

@dbaynard dbaynard commented Jan 8, 2019

And what's the precise error (please run with --verbose and paste the log)?

@Aarskin
Copy link

@Aarskin Aarskin commented Jan 8, 2019

stack ghci --verbose > log.txt

This isn't piping all of the output to the file; here is what gets piped (processing ghc-8.6.3.tar.xz)

stack_ghci_failure.txt

Here's the rest of the output that dumps to the console

Version 1.9.1, Git revision f9d0042c141660e1d38f797e1d426be4a99b2a3c (6168 commits) x86_64 hpack-0.31.0
2019-01-08 09:31:41.897723: [debug] Checking for project config at: S:\Relativity\stack.yaml
2019-01-08 09:31:41.898719: [debug] Checking for project config at: S:\stack.yaml
2019-01-08 09:31:41.899718: [debug] No project config file found, using defaults.
2019-01-08 09:31:41.902725: [debug] Run from outside a project, using implicit global project config
2019-01-08 09:31:41.903720: [debug] Decoding build plan from: C:\sr\build-plan\lts-13.1.yaml
2019-01-08 09:31:41.903720: [debug] Trying to decode C:\sr\build-plan-cache\lts-13.1.cache
2019-01-08 09:31:41.909718: [debug] Success decoding C:\sr\build-plan-cache\lts-13.1.cache
2019-01-08 09:31:41.922723: [debug] Potential GHC builds: standard
2019-01-08 09:31:41.922723: [debug] Found already installed GHC builds:
2019-01-08 09:31:42.040727: [debug] Trying to setup GHC build: standard
2019-01-08 09:31:42.041723: [info] Preparing to install GHC to an isolated location.
2019-01-08 09:31:42.041723: [info] This will not interfere with any system-level installation.
2019-01-08 09:31:42.042729: [info] Preparing to download ghc-8.6.3 ...
2019-01-08 09:31:42.043719: [debug] Downloading from https://github.com/commercialhaskell/ghc/releases/download/ghc-8.6.3-release/ghc-8.6.3-x86_64-unknown-mingw32.tar.xz to C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3.tar.xz ...
2019-01-08 09:31:42.043719: [debug] Will check against sha1 hash: 5a352e50ccf1deecc335300c5d8984ce863059b4
2019-01-08 09:31:42.043719: [debug] Will check against sha256 hash: 2fec383904e5fa79413e9afd328faf9bc700006c8c3d4bcdd8d4f2ccf0f7fa2a
2019-01-08 09:31:44.183718: [info] Already downloaded.
2019-01-08 09:31:44.188719: [info] Preparing to download 7z.dll ...
2019-01-08 09:31:44.188719: [debug] Downloading from https://github.com/fpco/minghc/blob/master/bin/7z.dll?raw=true to C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\7z.dll ...
2019-01-08 09:31:44.188719: [debug] Will check against sha1 hash: 168a288d4456f0473f66e86a2d6fec4eb6f4b993
2019-01-08 09:31:44.191724: [info] Already downloaded.
2019-01-08 09:31:44.191724: [info] Preparing to download 7z.exe ...
2019-01-08 09:31:44.191724: [debug] Downloading from https://github.com/fpco/minghc/blob/master/bin/7z.exe?raw=true to C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\7z.exe ...
2019-01-08 09:31:44.192720: [debug] Will check against sha1 hash: 187dff8a3327da87050f678579816e5bae40c632
2019-01-08 09:31:44.193724: [info] Already downloaded.
2019-01-08 09:31:44.195719: [debug] Run process: C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\7z.exe x -oC:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3-tmp20928\ -y C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3.tar.xz
2019-01-08 09:32:07.372461: [debug] Process finished in 23177ms: C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\7z.exe x -oC:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3-tmp20928\ -y C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3.tar.xz
2019-01-08 09:32:07.373461: [debug] Run process: C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\7z.exe x -oC:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3-tmp20928\ -y C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3-tmp20928\ghc-8.6.3.tar
2019-01-08 09:32:24.054863: [debug] Process finished in 16681ms: C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\7z.exe x -oC:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3-tmp20928\ -y C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3-tmp20928\ghc-8.6.3.tar
C:\Users\my.name\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.3-tmp20928\ghc-8.6.3\: renamePath:MoveFileEx "C:\\Users\\my.name\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.6.3-tmp20928\\ghc-8.6.3\\" "C:\\Users\\my.name\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.6.3\\": permission denied (Access is denied.)


@dbaynard
Copy link
Contributor

@dbaynard dbaynard commented Jan 8, 2019

OK, this is failing during stack setup. There are a few other (more recent) related issues — if you search the issue tracker for 'permission denied' you'll find them. Typically you may need to manually delete directories, or check antivirus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants