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

storage: fix up docstring comments #1

Closed
wants to merge 1 commit into from
Closed

storage: fix up docstring comments #1

wants to merge 1 commit into from

Conversation

cyphar
Copy link
Contributor

@cyphar cyphar commented Oct 5, 2016

In order to make actually reading the interfaces easier (as well as
making godoc actually useful), we need to comment the interface methods
themselves rather than the whole interface.

Signed-off-by: Aleksa Sarai [email protected]

In order to make actually reading the interfaces easier (as well as
making godoc actually useful), we need to comment the interface methods
themselves rather than the whole interface.

Signed-off-by: Aleksa Sarai <[email protected]>
@nalind
Copy link
Member

nalind commented Oct 5, 2016

Looks good, merging.

@nalind nalind closed this Oct 5, 2016
@cyphar cyphar deleted the fix-docstrings branch October 5, 2016 12:45
@cyphar
Copy link
Contributor Author

cyphar commented Oct 5, 2016

Uhh d4ee4f6 isn't a merge, you took my commit then stripped my Signed-off-by and my authorship (while also changing the patch slightly). I understand that it's "just" a comment change, but that's not how you merge external contributors' commits -- you're erasing copyright holder information from the repository.

@nalind
Copy link
Member

nalind commented Oct 5, 2016

Doh. That's what I get for using git merge instead of the web UI. Alright if I rewrite the history to try to restore it?

@nalind
Copy link
Member

nalind commented Oct 5, 2016

Oh, wait, those are two commits. 6a6198a should be exactly what was proposed.

@cyphar
Copy link
Contributor Author

cyphar commented Oct 5, 2016

Ah, my apologies. The short message was the same so I didn't think to go through the history (since there wasn't a merge commit). Sorry about that. :P

@nalind
Copy link
Member

nalind commented Oct 5, 2016

No worries. I'll try to use the web UI to do those in the future.

@cyphar
Copy link
Contributor Author

cyphar commented Oct 5, 2016

I actually don't like the Web UI either, but personally I always make sure to use --no-ff when using git merge because when you fast-forward master then you lose the merge history (this is what the Web UI does by default). If the top commit had been a merge commit I wouldn't have been confused. :P

@nalind
Copy link
Member

nalind commented Oct 5, 2016

Ah, so that's what I missed. Thanks for the tip!

kolyshkin added a commit to kolyshkin/storage that referenced this pull request May 16, 2020
This subtle bug keeps lurking in because error checking for `Mkdir()`
and `MkdirAll()` is slightly different wrt `EEXIST`/`IsExist`:

 - for `Mkdir()`, `IsExist` error should (usually) be ignored
   (unless you want to make sure directory was not there before)
   as it means "the destination directory was already there";

 - for `MkdirAll()`, `IsExist` error should NEVER be ignored.

This commit removes ignoring the IsExist error, as it should not
be ignored.

For more details, a quote from my opencontainers/runc#162 (July 2015):

-quote-

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:

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

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.

In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in containers#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 containers#1, IsExist check after MkdirAll is not needed.

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

Note this error is all over the tree, I guess due to copy-paste,
or trying to follow the same usage pattern as for Mkdir(),
or some not quite correct examples on the Internet.

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

-end-quote-

Signed-off-by: Kir Kolyshkin <[email protected]>
kolyshkin added a commit to kolyshkin/storage that referenced this pull request May 18, 2020
This subtle bug keeps lurking in because error checking for `Mkdir()`
and `MkdirAll()` is slightly different wrt `EEXIST`/`IsExist`:

 - for `Mkdir()`, `IsExist` error should (usually) be ignored
   (unless you want to make sure directory was not there before)
   as it means "the destination directory was already there";

 - for `MkdirAll()`, `IsExist` error should NEVER be ignored.

This commit removes ignoring the IsExist error, as it should not
be ignored.

For more details, a quote from my opencontainers/runc#162 (July 2015):

-quote-

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:

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

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.

In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in containers#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 containers#1, IsExist check after MkdirAll is not needed.

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

Note this error is all over the tree, I guess due to copy-paste,
or trying to follow the same usage pattern as for Mkdir(),
or some not quite correct examples on the Internet.

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

-end-quote-

Signed-off-by: Kir Kolyshkin <[email protected]>
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