Stack based projects are not possible on longer Windows paths

[varosi]

Steps to reproduce

For example:

1. Put your project on long path, like:
   C:\builder\jenkins\home\workspace\aaaaaaaaa_master-IH6I4ZJQUG22JDFTMS624VMTMO5APB7UUFMDD7ZRLLQLR32Y2H5A\aaaaaaaaa
2. Run command stack build.

Expected

To build correctly. When I move it out of our Jenkins to manual location - it works just fine.

Actual

C:\builder\jenkins\home\workspace\aaaaaaaaa_master-IH6I4ZJQUG22JDFTMS624VMTMO5APB7UUFMDD7ZRLLQLR32Y2H5A\aaaaaaaaa\.stack-work\install\609572cd\lib\x86_64-windows-ghc-8.0.2\integer-logarithms-1.0.1-9gv6iGGjwWmK292qSXr06v\Math\NumberTheory:
    copyFile: does not exist (No such file or directory)

Stack version

$ stack --version
Version 1.4.1, Git revision ea10057da1b1a49d937e7bcb6f997360bec1f863 (4765 commits) x86_64 hpack-0.17.0

Windows 8.1 x64

Method of installation

• Official GitHub

[snoyberg]

This sounds like you're hitting the 256 character limit on Windows, which isn't something we can work around effectively.

[varosi]

I think so. There could be different ways to overcome that. One is to use relative paths, so paths will be much shorter.

There some other ways:

• https://stackoverflow.com/questions/2825798/should-i-deal-with-files-longer-than-max-path
• https://stackoverflow.com/questions/3277717/c-winapi-handling-long-file-paths-names

[snoyberg]

I'm open to any PRs to try and address that, but last time I investigated this, it would require deep changes throughout at least GHC, and possibly through the GNU tools as well.

[varosi]

We overcome the problem with "subst" that path to a separate drive, so we could work with shorter paths.

[varosi]

hm, for GHC 8.4 there are plans for supporting long paths on Windows:
https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1

[dnadales]

Another problem I ran into is when creating projects with long names on Windows. For example:

stack new this-is-a-very-long-package-name
cd this-is-a-very-long-package-name
stack setup
stack build

Then the build will fails with the following message:

C:\Users\nadalesagutde\Documents\github\capitanbatata\sandbox\this-is-a-very-long-package-name\.stack-work\install\5600629f\bin
copyFile: does not exist (The system cannot find the path specified.)
'cabal copy' failed.  Error message:

--  While building package this-is-a-very-long-package-name-0.1.0.0 using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack-work\dist\ca59d0ab copy
    Process exited with code: ExitFailure 1

One possible cause of this issue is:
* No module named "Main". The 'main-is' source file should usually have a header indicating that it's a 'Main' module.

which is quite misleading. I'm adding this comment in case somebody else runs into this.

[varosi]

Here is some light (note) on the issue:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364963(v=vs.85).aspx

Tip Starting in Windows 10, version 1607, for the unicode version of this function (GetFullPathNameW), you can opt-in to remove the MAX_PATH character limitation without prepending "\?". See the "Maximum Path Limitation" section of Naming Files, Paths, and Namespaces for details.

[Ailrun]

Is there any update on this?

[mpilgrem]

I am closing this issue given the passage of time and because I could not reproduce a problem with that directory on Windows 11 using Stack 2.15.3 and a modern version of GHC.