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

InvalidAbsDir "./stack-setupXXXXX" from Path.IO.listDirectory #1017

Closed
robstewart57 opened this issue Sep 20, 2015 · 7 comments
Closed

InvalidAbsDir "./stack-setupXXXXX" from Path.IO.listDirectory #1017

robstewart57 opened this issue Sep 20, 2015 · 7 comments

Comments

@robstewart57
Copy link
Contributor

When I execute stack setup I'm getting this error:

$ stack setup
InvalidAbsDir "./stack-setup31658"

This is thrown by Path.parseAbsDir in the path package (see line 79). I've modified Path.IO.listDirectory to print the filepath it is calling parseAbsDir on, so that the file path is printed each time and also so that I can get the stack trace up to that point.

This is the printed file paths and the stack trace:

"/home/rob/.stack/programs/i386-linux/ghc-7.10.2.tar.xz"
"/home/rob/.stack/programs/i386-linux/.."
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Path.CAF
  --> evaluated by: Path.IO.listDirectory.\,
  called from Path.IO.listDirectory,
  called from Stack.Setup.listInstalled,
  called from Stack.Setup.ensureGHC,
  called from Stack.Types.StackT.>>=,
  called from Main.setupCmd.\,
  called from Main.withUserFileLock.\,
  called from Main.withUserFileLock,
  called from Main.setupCmd,
  called from Main.main.\,
  called from Data.Attoparsec.Args.withInterpreterArgs,
  called from Main.main

I've raised this question with @chrisdone who believes that stack should canonicalize paths before calling parseAbsDir.

@mgsloan
Copy link
Contributor

mgsloan commented Sep 20, 2015

configLocalPrograms seems to be well canonicalized, here, so it must not be the input to listDirectory that's the issue.

It's very surprising that there'd be a bug in listDirectory, though (you'd think it'd always happen, and be caught quickly).

Lets test out chris's thought - does this fix it?

diff --git a/src/Path/IO.hs b/src/Path/IO.hs
index ca1bed9..79e6d39 100644
--- a/src/Path/IO.hs
+++ b/src/Path/IO.hs
@@ -170,8 +170,9 @@ listDirectory dir =
   do entriesFP <- liftIO (D.getDirectoryContents dirFP)
      maybeEntries <-
        forM (map (dirFP ++) entriesFP)
-            (\entryFP ->
-               do isDir <- liftIO (D.doesDirectoryExist entryFP)
+            (\entryFP' ->
+               do entryFP <- liftIO (D.canonicalizePath entryFP')
+                  isDir <- liftIO (D.doesDirectoryExist entryFP)
                   if isDir
                      then case parseAbsDir entryFP of
                             Nothing -> return Nothing

@chrisdone
Copy link
Member

The calls to parseAbsDir inside listDirectory are in the Maybe monad so I don't see why an exception would be thrown from within listDirectory.

@chrisdone
Copy link
Member

@robstewart57 Can you offer some extra details so that we can reproduce this?

robstewart57 added a commit to robstewart57/stack that referenced this issue Sep 20, 2015
… Stack.Setup

The System.IO.Temp withSystemTempDirectory function from
System.IO.Temp used in Stack.Setup returns a non-canonicalised
path. However, the parseAbsDir function in the Path module of the path
library expects canonicalised paths.

The change is applied to stack setup, `sanityCheck` and stack upgrade
in Stack.Setup .

Fixes commercialhaskell#1017
@robstewart57
Copy link
Contributor Author

In fact, I wasn't reading the stack trace in the right way. It turns out that the issue was with Stack.Setup whenever withSystemTempDirectory is used, e.g.

withSystemTempDirectory "stack-setup" $ \root' -> do
root <- parseAbsDir root'

At least for me, the withSystemTempDirectory was not returning a canonicalised path, which is why parseAbsDir from the path library was throwing the error.

I propose a PR that applies a fix to stack setup, sanityCheck and stack upgrade
in Stack.Setup : #1019 .

@robstewart57
Copy link
Contributor Author

Hang off accepting this PR actually, this same problem is causing a problem elsewhere. More anon...

robstewart57 added a commit to robstewart57/stack that referenced this issue Sep 20, 2015
… Stack.Build.Execute

Relates to 7be7843 , which fixes the
same instances of this pattern, in Stack.Setup .

This does appear to fix commercialhaskell#1017 .
@robstewart57
Copy link
Contributor Author

OK, that second commit ( f912e2f ) does appear to fix the InvalidAbsDir error I was getting. This PR is ready for review #1019 .

@snoyberg
Copy link
Contributor

Closing so that we follow up on the PR (#1019).

robstewart57 added a commit to robstewart57/stack that referenced this issue Sep 24, 2015
When the $TMPDIR environment variable is set, the directory paths
provided by `withSystemTempDirectory` and `withTempDirectory` from
System.IO.Temp provided by the temporary library are not
canonicalised. This commit wraps these functions into canonicalized
versions.

See an earlier PR for discussion commercialhaskell#1019

Fixes commercialhaskell#1017
robstewart57 added a commit to robstewart57/stack that referenced this issue Sep 24, 2015
When the $TMPDIR environment variable is set, the directory paths
provided by `withSystemTempDirectory` and `withTempDirectory` from
System.IO.Temp provided by the temporary library are not
canonicalised. This commit wraps these functions into canonicalized
versions.

See an earlier PR for discussion commercialhaskell#1019

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

No branches or pull requests

4 participants