I don't see anything particularly wrong (aside from the redundant path). If you can reliably reproduce this, could you use https://technet.microsoft.com/en-us/sysinternals/bb896645 (set the filter to cabal.exe to reduce the noise) and you should be able to see the actual error from the file system.

Can you copy and paste the log for that entry here? or a screenshot.

The problem is probably

withTempIncomingDir :: StoreDirLayout -> CompilerId
                    -> (FilePath -> IO a) -> IO a
withTempIncomingDir StoreDirLayout{storeIncomingDirectory} compid action = do
    createDirectoryIfMissing True incomingDir
    withTempDirectory silent incomingDir "new" action
  where
    incomingDir = storeIncomingDirectory compid

from b05b9ae. CC @dcoutts who introduced this code.

The error doesn't say which file copy failed. the path shown is just the base path. so maybe when the filename is added it does pass the MAX_PATH limit.

@Mistuke I monitored cabal new-build all for cabal repo and attached the log!
cabal.zip

Hmm the log doesn't contain any actual errors. All the accesses succeed and the file copies do as well.
e.g, filtering on

C:\Users\abiehl\AppData\Roaming\cabal\store\ghc-8.0.2\incoming\new-13036\Users\abiehl\AppData\Roaming\cabal\store\ghc-8.0.2\

I see no failures.

System.Directory does copyFile by first creating a temp file, writing to it and then renaming it, hence I see the proper IRP_MJ_CREATE, IRP_MJ_WRITE, IRP_MJ_CLEANUP, IRP_MJ_SET_INFORMATION sequence that I would expect for these file operations all with a result of SUCCESS. The longest path written seems to be 238 characters.

I guess the duplicate path should be fixed first, if that fixes the issue then it's a path length error. (though System.Directory seems to attempt to use \\?\ paths to work around the limit.

So, the redundant path arises because of the copy command issued in 3b8ee83#diff-d998ae67b007b4623e9c789feb2c47abR929.

we have the destDir with C:\\...\store\incoming\new-*\ now absoluteInstallDirs constructs the copy destination path like destDir </> dropDrive $prefix/... which results in the long redundant path from above.

Can we issue a cabal copy which doesn't append $prefix to destDir?

But surely that can't be intended? If it's a prefix why is it being used as a suffix? also isn't the very fact that it's dropping the drive from a full path suspicious?

It seem it is. Here a few sources:

• cabal/Cabal/Distribution/Simple/Setup.hs

  Line 906 in 99e70bd

  ++ "Does not call register, and allows a prefix at install time. "

• https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/ProjectBuilding.hs#L930
• https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/InstallDirs.hs#L289

Not sure if this is the same problem but I've got this while building a project using new-build that uses the cryptohash-md5 and sha1 libraries. The log file is attached.

Windows 10
cabal-install version 2.0.0.0
compiled using version 2.0.0.2 of the Cabal library
The Glorious Glasgow Haskell Compilation System, version 8.0.2

cryptohash-sh_-0.11.10_-10758d342786ef1cdd0d32ea6f9223fd5558133b.log.txt

@sumo I'm quite positive you're hitting the same problem. The new --store-dir flag (not yet in any officially released cabal) would most likely help workaround the issue you're observing.

I am also hitting the same issue with:

GHC8.2.2
cabal-install version 2.0.0.0
compiled using version 2.0.0.2 of the Cabal library

Error output:

Installing library in C:\Users\Nikolaos\AppData\Roaming\cabal\store\ghc-8.2.2\incoming\new-8792\Users\Nikolaos\AppData\Roaming\cabal\store\ghc-8.2.2\Win32-notify-0.3.0.3-0a14d99b334a049d77a1d7688280c4accca8ea6d\lib
copyFile: does not exist (The system cannot find the path specified.)ds]

I've made two PRs to address this. Each of which will fix this issue.
The first one makes it possible for cabal to issue copy/rename/create commands to paths longer than MAX_PATH and the second one fixes this path redundancy for the temporary incoming directories. See the PRs themselves for more detail.

Any update on this? This is still occuring.

@KaneTW Are you using cabal-install 2.2?

I no longer get this issue on

cabal-install version 2.2.0.0
compiled using version 2.2.0.1 of the Cabal library

Seems to have been fixed by #4977, closing.

I still get this error (on W10) when doing

PS> cabal get mmark-0.0.6.0; cd mmark-0.0.6.0; cabal new-build -w $(which ghc-8.2.2)
Unpacking to mmark-0.0.6.0\
Resolving dependencies...
Build profile: -w ghc-8.2.2 -O1
In order, the following will be built (use -v for more details):
...
 - semigroupoids-5.3.1 (lib:semigroupoids) (requires build)
...
Starting     mwc-random-0.14.0.0 (lib)
...
Completed    aeson-1.4.2.0 (lib)

Failed to build semigroupoids-5.3.1. The failure occurred during the final
install step.
Build log (
C:\Users\Sebastian\AppData\Roaming\cabal\logs\ghc-8.2.2\semigroupoids-5.3.1-75894acc0b028fcd0e8d0f987926cd380665a61a.log
):
Installing library in C:\Users\Sebastian\AppData\Roaming\cabal\store\ghc-8.2.2\incoming\new-18476\Users\Sebastian\AppData\Roaming\cabal\store\ghc-8.2.2\semigroupoids-5.3.1-75894acc0b028fcd0e8d0f987926cd380665a61a\lib
copyFile: does not exist (Das System kann den angegebenen Pfad nicht finden.)Functor\Bind\Class.o )
[ 3 of 21] Compiling Data.Functor.Apply ( src\Data\Functor\Apply.hs, dist\build\Data\Functor\Apply.o )
[ 4 of 21] Compiling Data.Functor.Bind ( src\Data\Functor\Bind.hs, dist\build\Data\Functor\Bind.o )
[ 5 of 21] Compiling Data.Functor.Bind.Trans ( src\Data\Functor\Bind\Trans.hs, dist\build\Data\Functor\Bind\Trans.o )
[ 6 of 21] Compiling Data.Functor.Alt ( src\Data\Functor\Alt.hs, dist\build\Data\Functor\Alt.o )
[ 7 of 21] Compiling Data.Bifunctor.Apply ( src\Data\Bifunctor\Apply.hs, dist\build\Data\Bifunctor\Apply.o )
[ 8 of 21] Compiling Data.Functor.Plus ( src\Data\Functor\Plus.hs, dist\build\Data\Functor\Plus.o )
[ 9 of 21] Compiling Data.Semigroupoid ( src\Data\Semigroupoid.hs, dist\build\Data\Semigroupoid.o )
[10 of 21] Compiling Data.Semigroupoid.Dual ( src\Data\Semigroupoid\Dual.hs, dist\build\Data\Semigroupoid\Dual.o )
[11 of 21] Compiling Data.Groupoid    ( src\Data\Groupoid.hs, dist\build\Data\Groupoid.o )
[12 of 21] Compiling Data.Isomorphism ( src\Data\Isomorphism.hs, dist\build\Data\Isomorphism.o )
[13 of 21] Compiling Data.Semigroupoid.Ob ( src\Data\Semigroupoid\Ob.hs, dist\build\Data\Semigroupoid\Ob.o )
[14 of 21] Compiling Data.Semigroupoid.Static ( src\Data\Semigroupoid\Static.hs, dist\build\Data\Semigroupoid\Static.o )
[15 of 21] Compiling Data.Traversable.Instances ( src\Data\Traversable\Instances.hs, dist\build\Data\Traversable\Instances.o )
[16 of 21] Compiling Data.Semigroup.Foldable.Class ( src\Data\Semigroup\Foldable\Class.hs, dist\build\Data\Semigroup\Foldable\Class.o )
[17 of 21] Compiling Data.Semigroup.Bifoldable ( src\Data\Semigroup\Bifoldable.hs, dist\build\Data\Semigroup\Bifoldable.o )
[18 of 21] Compiling Data.Semigroup.Foldable ( src\Data\Semigroup\Foldable.hs, dist\build\Data\Semigroup\Foldable.o )
[19 of 21] Compiling Data.Semigroup.Traversable.Class ( src\Data\Semigroup\Traversable\Class.hs, dist\build\Data\Semigroup\Traversable\Class.o )
[20 of 21] Compiling Data.Semigroup.Traversable ( src\Data\Semigroup\Traversable.hs, dist\build\Data\Semigroup\Traversable.o )
[21 of 21] Compiling Data.Semigroup.Bitraversable ( src\Data\Semigroup\Bitraversable.hs, dist\build\Data\Semigroup\Bitraversable.o )
cabal.exe: Failed to build semigroupoids-5.3.1 (which is required by
mmark-0.0.6.0). See the build log above for details.

From some -v3 output I suspected that it can't find transformers-_-0.6.2-b8f7fc3fedb8c7a1f1badeb1026d6d737257f6f0 (which is transformers-compat, I guess), maybe due to some path length limitations, I don't know. Here's the v3 log.

Can anyone with a windows machine reproduce? I tried this multiple times with different mmark versions (but the same semigroupoids-0.5.3.1). Building semigroupoids-0.5.3.1 in isolation works fine. It also works with ghc-8.4.3.

Hi, i've tried the build in windows 10 and it worked fine. In my case the path to tansformer is 187 chars long.
If the issue is related with the path maybe change the dir where new-build put the libs could help. You could add in the global config file (in %APPDATA%/cabal/config)

store-dir: C:\sd

That seems to have worked. But I was under the impression that windows path length shouldn't be an issue anymore. Is that not true?

Well, it seems that was at least partially fixed for cabal 2.2 (changelog). It seems ghc is involved too so it would explain the diff behaviour.