Add support on Windows for copying to long paths.

[Mistuke]

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• If the change is docs-only, [ci skip] is used to avoid triggering the build bots.

Please also shortly describe how you tested your change. Bonus points for added tests!

Tested by trying to compile cabal itself on a long path.

Should fix partially #3972, #4914, #4515. The reason why partial is because any operation that hits the GHC I/O manager will destroy device path support. Because the GHC I/O manager is using non-native posix like APIs which are mapped to the old Win32 APIs that are bound by MAX_PATH.

This patch works because it avoids touching the I/O manager for doing the file copy and instead does a direct copy using the Win32 API. The Windows APIs do not have the same limitations as the posix ones and so do not require the file to be on the same drive before issuing a copy/move. So this should be much faster too.

[Mistuke]

cc @alexbiehl , @hvr

[23Skidoo]

Do you reckon it'd make sense to implement a compat filepath layer that'd use extended length paths and native operations on Windows, and standard operations (System.Directory and friends) otherwise?

[23Skidoo]

LGTM.

[23Skidoo]

This breaks the build on non-Windows, where takeDirectory is still used, see e.g. https://travis-ci.org/haskell/cabal/jobs/321706530#L778.

[Mistuke]

@23Skidoo Well, System.Directory mostly does the right thing, it does convert to device paths and calls out to Win32 which calls the proper APIs. It's specifically copyFile that's problematic because of the limitations of the posix calls.

I only quickly glanced but I don't believe the other functions use the I/O manager and so should be fine. A "proper" fix would be a new I/O manager in GHC/base. I'm working towards an implementation, but it's a big task so not sure I'll finish by 8.6. But somewhere in the next two releases it should be done and then Cabal and cabal-install should just work without any changes.

[23Skidoo]

Build still fails on Linux, now due to -Werror:

Distribution/Compat/CopyFile.hs:145:1:
    Warning: Defined but not used: `toExtendedLengthPath'

[23Skidoo]

Merged, thanks!

[BardurArantsson]

Great work! Especially the bit about trying to upstream into base... :)

(Not that I'm using Windows, personally, but this has been a pain for Cabal users and package developers who want "cross-platform-by-default" for quite a while...)

[Mistuke]

For future reference, this workaround is no longer need when cabal is compiled with GHC 8.6. See ghc/ghc@4de585a