Simplify git_futils_mkdir #1635
Conversation
This routine was (is) pretty complicated, but given the recent changes, it seemed like it could be simplified a bit.
|
/cc @jamill - I know we're getting to a point of diminishing returns here, but what do you think about this simplification? |
| tail = &make_path.ptr[root]; | ||
|
|
||
| /* is there any path to make? */ | ||
| verify_final = ((flags & GIT_MKDIR_VERIFY_DIR) != 0) && (*tail != 0); |
There was a problem hiding this comment.
Is the second condition here (*tail != 0) meant to capture the case where the path is only the root? due to the above lines, tail is set to point to make_path.size - 1, so it will point to the char before the null char, and in Win32 will not be null (e.g. 'd:' will result in tail pointing to ':')
There was a problem hiding this comment.
In this case, the check is actually supposed to be whether there is any path to be created after all once the GIT_MKDIR_SKIP_LAST flag has been taken into account. Due to that flag, it is possible that there is literally no directory to be created and the final verification should not be done. This happens in the test suite where we end up calling git_futils_mkpath2file("filename", ...) with a relative filename that doesn't have a leading directory at all.
That being said, I didn't notice that the below line that advances the tail past the min_root_len is not successfully preventing the mkdir on the root. Let me address that (and also make the "SKIP_LAST has left nothing to do" easier to understand).
|
@arrbee I like the general direction, however, on Win32 this can still call |
There are two places where git_futils_mkdir should exit early or at least do less. The first is when using GIT_MKDIR_SKIP_LAST and having that flag leave no directory left to create; it was being handled previously, but the behavior was subtle. Now I put in a clear explicit check that exits early in that case. The second is when there is no directory to create, but there is a valid path that should be verified. I shifted the logic a bit so we'll be better about not entering the loop than that happens.
|
Okay, so I was able to get a bit further cleanup and, I think, make the logic clearer. Now if the path is brought to length zero by the |
|
Thanks arrbee, this seems good to me! |
Simplify git_futils_mkdir
This routine was (is) pretty complicated, but given the recent changes, it seemed like it could be simplified a bit.
What I decided is that the specific error from
p_mkdirdoesn't really matter. If we get an error from that routine, then we'll always stat the path we attempted to create and see if it is already a directory and continue if so (providedGIT_MKDIR_EXCLisn't being used). I also use that stat data to avoid a chmod if it isn't needed. And lastly, I shifted where the final stat forGIT_MKDIR_VERIFY_DIRis done so that even if we skip over a leading drive letter or network mount point, we'll still verify that the location is an actual existing directory.The bottom line is that this reduces the amount of code and, I think, makes it easier to follow. You have have to view the result instead of just viewing the diffs to be able to follow the changes. This is a place where side-by-side would really help.