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

Simplify and fix os.MkdirAll() usage #422

Merged
merged 1 commit into from
Aug 4, 2015
Merged

Conversation

kolyshkin
Copy link
Contributor

Please review; I think it's of moderate importance as ignoring error from MkdirAll can lead to some other error later and it could be hard to track the cause down to failed MkdirAll.

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 <[email protected]>
@kolyshkin
Copy link
Contributor Author

Here's an example
http://play.golang.org/p/xcuYZ1YtyZ

@mavenugo
Copy link
Contributor

mavenugo commented Aug 3, 2015

@kolyshkin Thanks for the patch. The existing code ignores the error ONLY for the case of EEXIST. If, as per your example, the call os.MkdirAll doesn't fail with EEXIST, then it is fine. The code will just work as is. But, if it fails with ENOTDIR, then we return the error as expected.
Also, this behavior seems to be OS specific. Hence should we confirm the behavior of isExist across OSes before removing that check ?

@kolyshkin
Copy link
Contributor Author

@mavenugo The thing is, it is wrong to ignore EEXIST error, too. In its current implementation (https://golang.org/src/os/path.go#L12), MkdirAll() can actually return EEXIST in a case of the following race (which I admit I was too lazy to explain in details, but here you go).

First, MkdirAll calls stat() and gets ENOENT, so it goes on to check and create all the parents. At this time, someone else creates a file under the same name as the last MkdirAll component. Finally, MkdirAll calls Mkdir to create that last component, Mkdir returns EEXIST which MkdirAll passes to the caller.

Having said that, the race should be pretty rate, this is why I named my commit "Simplify and fix" not "Fix and simplify". This extra check is redundant in the first place.

As of OS dependent, I admit I have UNIX/Linux in mind and don't know much about other platforms, but MkdirAll is definitely not OS-specific. Although Mkdir (which it calls) is OS-specific, it should be wrong to ignore its errors on any platform.

@mavenugo
Copy link
Contributor

mavenugo commented Aug 4, 2015

@kolyshkin Thanks for the explanation. As you understand, Ignoring the EExist is a lazy way to make sure we dont fail if the directory is already available. Hence, if we decide to return the EExist error, then it is going to impact the rest of the code which has some assumptions on createBasePath.
If we decide to go with this patch, we have to fix this assumption appropriately.
Though we cannot do it in an atomic way, we could check for the presence of the directory before calling MkdirAll and returning the error.
I wouldn't be happy to go with the observation made in http://play.golang.org/p/xcuYZ1YtyZ which executes in a particular OS and a specific environment. am more interested in making sure the current assumption is honored. Which is, createBasePath creates the base base directory if not already available (or) return a success if it is already available.

@kolyshkin
Copy link
Contributor Author

Ignoring the EExist is a lazy way to make sure we dont fail if the directory is already available.

No. Please re-read my patch description. Let me quote the relevant part:

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.

Also, I went ahead and checked that the current implementation of MkdirAll() is in sync with the above quoted documentation (i.e. it doesn't return EEXIST error if the directory is there), and that it is also OS-independent.

So, once again, the check for EEXIST after MkdirAll() is at the very least redundant.

@mavenugo
Copy link
Contributor

mavenugo commented Aug 4, 2015

@kolyshkin yep. I missed that point. Thanks.

LGTM.
cc @aboch

@kolyshkin
Copy link
Contributor Author

BTW my similar pull requests to Docker and RunC are merged:

@aboch
Copy link
Contributor

aboch commented Aug 4, 2015

Thanks @kolyshkin for the explanation.

LGTM

aboch added a commit that referenced this pull request Aug 4, 2015
Simplify and fix os.MkdirAll() usage
@aboch aboch merged commit bdcd5a8 into moby:master Aug 4, 2015
@kolyshkin kolyshkin deleted the mkdirall branch August 5, 2015 03:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants