[GHC] #13373: Handle long file paths on Windows

[GHC]

#13373: Handle long file paths on Windows
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  libraries/base    |              Version:  8.1
      Resolution:                    |             Keywords:
Operating System:  Windows           |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Old description:

> 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:
>
> * https://github.com/haskell/cabal/issues/3972
> * https://ghc.haskell.org/trac/ghc/ticket/10777
>
> 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.
> * 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.

New description:

 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:

 * https://github.com/haskell/cabal/issues/3972
 * https://ghc.haskell.org/trac/ghc/ticket/10777

 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.
 * 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.

--

Comment (by ezyang):

 I stand corrected. :)

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13373#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler