Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store "stack-path" files in directories that have been shortened with SHAs #1173

Closed
mgsloan opened this issue Oct 16, 2015 · 3 comments
Closed
Assignees
Milestone

Comments

@mgsloan
Copy link
Contributor

mgsloan commented Oct 16, 2015

The resolution for #1145 / #1027 is to replace some long paths with 8 character SHAs on windows, due to the MAX_PATH limitation. It would be good to store a file, maybe called SHA/stack-path, with the path that would have been used in place of the SHA. This is useful for a variety circumstances:

It gets a little bit tricky to ensure that every possible execution involving these paths will also create the path file, though. These paths are used in quite a few places, and often they get created be external tools.

/me shakes fist menacingly at MAX_PATH

@mgsloan mgsloan self-assigned this Oct 16, 2015
@DemiMarie
Copy link

Another solution is to do what CoreCLR is doing – have GHC implicitly use extended paths.

@mgsloan
Copy link
Contributor Author

mgsloan commented Oct 23, 2015

It gets a little bit tricky to ensure that every possible execution involving these paths will also create the path file, though. These paths are used in quite a few places, and often they get created be external tools.

I'm thinking that the solution here is to have an in-memory cache of whether a particular path.yaml file has been written - something like Set (Path Abs Dir). Then we can just check this cache each time the paths are used. While this is slightly less efficient than statically knowing when to initialize these path.yaml files, it also seems less error-prone.

Creating these path.yaml files also means creating the folders. This means that functions like installationRootLocal, installationRootDeps, and distRelativeDir will have the side effect of creating the folders, when on windows. This seems relatively benign to me, but I think it makes sense to also create the folders on linux, for the sake of consistency.

@snoyberg
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants