-
Notifications
You must be signed in to change notification settings - Fork 243
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
pkg/lockfile: nits #1336
pkg/lockfile: nits #1336
Conversation
Since commit 162a0bf, openLock creates a file even if ro is set, but the documentation says otherwise. Since commit 16de6d3, openLock also creates file's parent directories if needed, but the documentation doesn't say that. Fix both issues. Signed-off-by: Kir Kolyshkin <[email protected]>
Since commit 162a0bf, openLock creates a file in case ro argument is set, but the file is created with 0 permission bits. Fix this, and unify the file creation logic while at it. Signed-off-by: Kir Kolyshkin <[email protected]>
unix.Open returns a bare error (like EPERM). This is worked around in on user, (*lockfile).lock, where we panic, but not in the other user, createLockerForPath, and as a result such a bare error might be returned from GetLockfile or GetROLockfile. Wrap it into os.PathError and remove the workaround from lockfile.lock. Signed-off-by: Kir Kolyshkin <[email protected]>
) | ||
flags := os.O_RDONLY | unix.O_CLOEXEC | os.O_CREATE | ||
if !ro { | ||
flags |= os.O_RDWR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This relies on the fact that O_RDONLY value is 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That’s
- Extremely non-obvious to careless users.
- Not guaranteed to be true, and in fact not true on at least one Go-supported platform right now (though, to be fair, not a platform currently supported by Podman).
Please just do the obviously-correct thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More generally, the assumption is O_RDONLY does not have any bits set that O_RDWR doesn't.
That is true even for zOS (the only Golang platform where O_RDONLY != 0). In zOS, O_RDONLY is 2 and O_RDWR is 3.
Having said that, your code is definitely better as it does not have any such undocumented assumptions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Fix one issue and a couple of nits in pkg/lockfile. Please see individual commits for details.