In the past, Cabal and GHC have run into Windows' PATH_MAX path size limitation, which caps the length of file system paths at 260 characters. Examples:

It would be really great if Haskell's base libraries handled long file system paths correctly. There are a few possibilities for achieving this:

Call GetShortPathName https://msdn.microsoft.com/en-us/library/windows/desktop/aa364989(v=vs.85).aspx before calling any Windows API function, if we notice the file path is too long. The bad: Windows has to store the alias, and this aliasing mechanism may be disabled ~~(but maybe this never happens in practice).~~

Rewrite the core libraries to use the Unicode versions of functions, which support longer paths. We need to add the \\?\ prefix in this case. However, this prefix is not supported by all functions, and it turns off automatic expansion in the path string (so .. is not interpreted.) Care would need to be taken to not break existing code.

prefix in this case. However, this prefix is not supported by all functions, and it turns off automatic expansion in the path string (so is not interpreted.) Care would need to be taken to not break existing code. For Windows 10 only, opt into transparent long path support using a manifest. See the bottom of https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx\#maxpath Downside: this only works for Windows 10

An alternative plan is to build and publish an alternative Windows IO library, which is a drop-in replacement for the IO functionality implemented in base but is long paths. We can use this to test paths and provide better functionality to old versions of GHC, before merging the changes back into base proper.