os: RemoveAll no longer returns *os.PathError

[colincross]

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

$ go version
go version go1.12 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"

What did you do?

In go 1.11, os.RemoveAll returned an *os.PathError when it failed to remove something due to a permissions issue. While not documented in the godoc for os.RemoveAll, this behavior was useful to implement a retry loop that attempted to chown the failing path and then call os.RemoveAll again (for example, https://android.googlesource.com/platform/build/soong/+/ef36053829238e24088c578eeac08a1693177757/ui/build/util.go#74). In go 1.12 os.RemoveAll returns a syscall.Errno instead, which doesn't tell the caller which path failed.

This test passes on go 1.11 but fails on go 1.12:

package main

import (
	"io/ioutil"
	"os"
	"path/filepath"
	"testing"
)

func TestRemoveAllPathError(t *testing.T) {
	tmpDir, err := ioutil.TempDir("", "")
	if err != nil {
		t.Fatal(err)
	}
	defer func() {
		err := os.RemoveAll(tmpDir)
		if err != nil {
			t.Errorf("Error removing tmpDir: %v", err)
		}
	}()

	a := filepath.Join(tmpDir, "a")
	b := filepath.Join(a, "b")

	os.Mkdir(a, 0755)
	os.Mkdir(b, 0755)
	os.Chmod(a, 0555)
	defer os.Chmod(a, 0755)

	err = os.RemoveAll(a)
	if pathErr, ok := err.(*os.PathError); ok {
		if pathErr.Path != b {
			t.Errorf("expected pathErr.Path %q, was %q", b, pathErr.Path)
		}
	} else {
		t.Errorf("expected os.PathError, got %T", err)
	}
}

On go 1.11 this test passes, but fails on go 1.12:

--- FAIL: TestRemoveAllPathError (0.00s)
    removeall_test.go:36: expected os.PathError, got syscall.Errno

Should os.RemoveAll always return a *os.PathError?

[gopherbot]

Change https://golang.org/cl/164720 mentions this issue: os: fix os.RemoveAll no longer returns *os.PathError

[oiooj]

I think we need to add a release-blocker label. @ianlancetaylor

[ianlancetaylor]

I don't think this is technically a release blocker.

[bradfitz]

Also, the release is already out. What would it block?

[dgryski]

@bradfitz I think the point it be in 1.12.1 or 1.13 on the assumption that changing the returned error type in 1.12 (which the documentation doesn't guarantee anyway, unlike some other calls) is an important API breakage.

[bradfitz]

Oh, if that was a request to cherry-pick the fix to Go 1.12.x, I agree. I'll let @ianlancetaylor approve.

[julieqiu]

friendly ping @ianlancetaylor - waiting on your approval for this cherry pick candidate

[ianlancetaylor]

@julieqiu There is nothing to cherry pick yet.

I agree that if the fix to master is sufficiently simple and safe then it should be cherry picked to the 1.12 branch. But at least to me it doesn't make sense to approve a cherry pick without knowing what we are cherry picking.