build: vague error when TMPDIR is set to directory that doesn't exist

[christophermanning]

What version of Go are you using (go version)?

go version go1.5.1 linux/amd64

What operating system and processor architecture are you using?

Linux 2dddcbe0e2db 4.0.9-boot2docker #1 SMP Thu Sep 10 20:39:20 UTC 2015 x86_64 GNU/Linux

What did you do?

Ran docker run --rm -it golang:1.5.1 /bin/bash -c "uname -a && go version && TMPDIR=/foo go build"

This is a simple example that represents setting TMPDIR to a directory that doesn't exist.

What did you expect to see?

An error telling me that TMPDIR is incorrectly set to a directory that doesn't exist.

What did you see instead?

a vague no such file or directory error (I'm using go build here against no go files, but it fails the same way even if I point to a valid main.go file.)

> docker run --rm -it golang:1.5.1 /bin/bash -c "uname -a && go version && TMPDIR=/foo go build"
Linux 2dddcbe0e2db 4.0.9-boot2docker #1 SMP Thu Sep 10 20:39:20 UTC 2015 x86_64 GNU/Linux
go version go1.5.1 linux/amd64
mkdir /foo/go-build017854532: no such file or directory

Since the error is so vague, I was initially scouring my go code for the misconfiguration, but the failure seems to happen before any go code is processed.

[minux]

Unless we check for this case explicitly, i don't think we can generate any
better error messages.

PS: when debugging problems like this, go build -x will generally lead you
to the problem faster.

The problem is that normally cmd/go tolerates a lot of missing directories
because it calls os.MkdirAll to create directories, except for one case:
when it needs to create the initial $WORK directory, it calls
ioutil.TempDir("", "go-build")
which will not create $TMPDIR if it doesn't exist. And I think that's a
reasonable choice (because $TMPDIR is supposed to always exist and
should be created by root due to the special sticky bit requirement.)

And I don't think ioutil.TempDir should check for the case where $TMPDIR
doesn't exist and generate a new error message. The existing message is
arguably good enough already: "mkdir /xxx/yyy: no such file or directory"
means mkdir syscall returns ENOENT, and that signifies that the parent
directory doesn't exist or there is a bad symlink somewhere.

[rakyll]

We provide os.TempDir and letting users to run arbitrary file operations on the returned value. On the other hand, the temp directory's status may change in the lifecycle of the Go program. It could be removed, created, mounted, unmounted, etc. From the Go context, without intercepting every file operation and checking whether the user is trying to access a TMPDIR directory or file, it is impossible to generate better error messages.

Should we intercept each file op such as os.Open to provide better error messages if the specific file or directory is in the temp directory? It doesn't sound like the expected behavior to me given the fact users can log TMPDIR related error messages with more context in their programs.

[minux]

Yeah, I think we can't do anything here. Even if we fixed ioutil.TempDir to check for the case, there could be other cases where the code tries to use the temporary directory and fails. It doesn't make sense to check for this special case everywhere in package os. Closing as unfortunate.

[christophermanning]

Thank you for the detailed replies and for the tip on go build -x

I understand that changing the behavior of ioutil.TempDir would be a bit unwieldy. I appreciate that usage of ioutil.TempDir in user code when TMPDIR has gone away for some reason can be left for the user to manage.

My main concern is that a missing TMPDIR can cause go build to fail before any user code is interpreted. For example, go build -h fails with the same mkdir error:

> docker run --rm -it golang:1.5.1 /bin/bash -c "uname -a && go version && TMPDIR=/foo go build -h"
Linux 0e893747f98c 4.0.9-boot2docker #1 SMP Thu Sep 10 20:39:20 UTC 2015 x86_64 GNU/Linux
go version go1.5.1 linux/amd64
mkdir /foo/go-build666391459: no such file or directory

If providing a better error message after go build runs when TMPDIR doesn't exist cannot be fixed without changing the internal behavior of ioutil.TempDir, then I accept this as being unfortunate.