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

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

millerresearch opened this issue Apr 20, 2020 · 1 comment


Copy link

@millerresearch millerresearch commented Apr 20, 2020

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/ '.../gopath/pkg/mod/cache/download/' 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.

Copy link

@gopherbot gopherbot commented Apr 21, 2020

Change mentions this issue: os: correct bad PathError message from FileOpen with O_CREATE on Plan 9

@gopherbot gopherbot closed this in 664d270 Apr 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.