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

Add implementation and test for SetIPForwarding() #3

Merged
merged 1 commit into from
Mar 4, 2015
Merged

Add implementation and test for SetIPForwarding() #3

merged 1 commit into from
Mar 4, 2015

Conversation

aboch
Copy link
Contributor

@aboch aboch commented Mar 4, 2015

  • Addressed Arnaud's comments

Signed-off-by: Alessandro Boch aboch@socketplane.io

- Addressed Arnaud's comments

Signed-off-by: Alessandro Boch <aboch@socketplane.io>
@icecrime
Copy link

icecrime commented Mar 4, 2015

LGTM 🎉

icecrime pushed a commit that referenced this pull request Mar 4, 2015
Add implementation and test for SetIPForwarding()
@icecrime icecrime merged commit 1bb681b into moby:master Mar 4, 2015
kolyshkin added a commit to kolyshkin/libnetwork that referenced this pull request Jul 30, 2015
TL;DR: check for IsExist(err) after a failed MkdirAll() is both
redundant and wrong -- so two reasons to remove it.

Quoting MkdirAll documentation:

> MkdirAll creates a directory named path, along with any necessary
> parents, and returns nil, or else returns an error. If path
> is already a directory, MkdirAll does nothing and returns nil.

This means two things:

1. If a directory to be created already exists, no error is
returned.

2. If the error returned is IsExist (EEXIST), it means there exists
a non-directory with the same name as MkdirAll need to use for
directory. Example: we want to MkdirAll("a/b"), but file "a"
(or "a/b") already exists, so MkdirAll fails.

The above is a theory, based on quoted documentation and my UNIX
knowledge.
3. In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in moby#2, with the exception when
there is a race between MkdirAll and someone else creating the
last component of MkdirAll argument as a file. In this very case
MkdirAll() will indeed return EEXIST.

Because of moby#1, IsExist check after MkdirAll is not needed.

Because of moby#2 and moby#3, ignoring IsExist error is just plain wrong,
as directory we require is not created. It's cleaner to report
the error now.

[1] https://github.com/golang/go/blob/f9ed2f75/src/os/path.go

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
clnperez pushed a commit to clnperez/libnetwork that referenced this pull request Aug 13, 2015
TL;DR: check for IsExist(err) after a failed MkdirAll() is both
redundant and wrong -- so two reasons to remove it.

Quoting MkdirAll documentation:

> MkdirAll creates a directory named path, along with any necessary
> parents, and returns nil, or else returns an error. If path
> is already a directory, MkdirAll does nothing and returns nil.

This means two things:

1. If a directory to be created already exists, no error is
returned.

2. If the error returned is IsExist (EEXIST), it means there exists
a non-directory with the same name as MkdirAll need to use for
directory. Example: we want to MkdirAll("a/b"), but file "a"
(or "a/b") already exists, so MkdirAll fails.

The above is a theory, based on quoted documentation and my UNIX
knowledge.
3. In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in moby#2, with the exception when
there is a race between MkdirAll and someone else creating the
last component of MkdirAll argument as a file. In this very case
MkdirAll() will indeed return EEXIST.

Because of moby#1, IsExist check after MkdirAll is not needed.

Because of moby#2 and moby#3, ignoring IsExist error is just plain wrong,
as directory we require is not created. It's cleaner to report
the error now.

[1] https://github.com/golang/go/blob/f9ed2f75/src/os/path.go

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
mavenugo added a commit to mavenugo/libnetwork that referenced this pull request Oct 31, 2016
Merging to latest windows-mh-overlay with my Service disovery changes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants