git_repository_init_ext doesn't return when non-existent path contains subdirectory

[bording]

Originally reported in libgit2/libgit2sharp#1664, it appears that git_repository_init_ext never returns if the path passed in via repo_path contain a subdirectory.

For example, passing in c:\foo when it doesn't exist works fine. Passing in c:\foo\foo when c:\foo doesn't exist causes it to never return.

For drives that don't exist, x:\foo returns the appropriate error. x:\foo\foo never returns.

Reproduction steps

Here's how it's being called from LibGit2Sharp:
https://github.com/libgit2/libgit2sharp/blob/72a5be4860779e5d2fd6d2900d3dcc119588fbc9/LibGit2Sharp/Core/Proxy.cs#L2471-L2484

Expected behavior

git_repository_init_ext should return with appropriate error code.

Actual behavior

git_repository_init_ext never returns

Version of libgit2 (release number or SHA1)

572e4d8

Operating system(s) tested

Win10

[pks-t]

Sorry, but I'm not able to reproduce this. E.g. the following testcase works just fine:

void test_repo_open__nonexisting_subdir(void)
{
	git_repository_init_options opts = GIT_REPOSITORY_INIT_OPTIONS_INIT;
	git_repository *repo;

	cl_git_fail(git_repository_init_ext(&repo, "C:\\non\\existing", &opts));
}

I also didn't see anything special in how you invoke git_repository_init_ext. Do you pass any special options to the function, e.g. do you set a different workdir path or set the bare flag? Otherwise, would you possibly be able to create a simple C reproducer?

[bording]

It's definitely occurring when LibGit2Sharp calls it, and I can see that the call into libgit2 never returns. Perhaps it's something in how LibGit2Sharp is calling it, then.

Otherwise, would you possibly be able to create a simple C reproducer?

Unfortunately, that's not likely something I'll be able to do. I haven't touched C since college. Perhaps @ethomson might be able to since he's involved on both sides here?

[Pinski]

Hi, just wondering if there's a status update on this?

I've tried to write protections around LibGit2Sharp to make sure this doesn't occur, but they aren't fool proof apparently. I'm often having to manually fiddle with rebooting servers and starting/stopping IIS in production environments because this bug maxes out my CPU. Curious if there's any progress before I spend more time writing defenses for all calls to LibGit2Sharp.

Thanks.

[pks-t]

@Pinski: @ethomson has opened a PR #5050 that aims to fix this issue. Verifying his proposed fix would certainly be welcome

[ethomson]

I think that I'll need to create a LibGit2Sharp patch with this for @Pinski to validate.

[Pinski]

Yeah, I would need a build of LibGit2Sharp with this fix to validate.