os: wrong PathError from OpenFile in Plan 9 causing lockedfile.Mutex failure

[millerresearch]

Some subrepo tests (like this one) are failing on Plan 9 while installing modules, when the attempt to create and lock a lockedfile.Mutex fails. The error message looks like:

go: can't lock version list lockfile: open /boot/glenda/workdir-pi3plus2/gopath/pkg/mod/cache/download/golang.org/x/net/@v/list.lock: '.../gopath/pkg/mod/cache/download/golang.org/x/net/@v/list.lock' does not exist

This message seems not to make sense, because the Mutex.Lock function works by opening the lock file with O_CREATE mode and os.ModeExclusive permission: a "does not exist" error should be impossible.

The underlying problem arises because Plan 9 OpenFile implements O_CREATE in the absence of O_TRUNC in two steps. To avoid truncating an existing file with the Create syscall, it first attempts to open the file, and if that fails because the file doesn't exist, it then calls Create. But -- here's where it goes wrong -- if the Create fails (in this case because of a race with another process which has created and locked it with os.ModeExclusive) the PathError returned from OpenFile is the original "does not exist" message from the first open attempt. This causes the Mutex.Lock function to give up; whereas if it had received a PathError with "file is locked" from the Create attempt, it would keep retrying until the lock is obtained.

I'll submit a CL shortly.

[gopherbot]

Change https://golang.org/cl/229099 mentions this issue: os: correct bad PathError message from FileOpen with O_CREATE on Plan 9