Skip to content

Repositories on UNC paths fail #153

Closed
chrisparnin opened this Issue May 19, 2012 · 5 comments

3 participants

@chrisparnin

I encountered this issue when using network paths to host source repositories. This sort of scenario is common when using a virtual machine or network drives as per company policy.

var path = @"\\psf\Home\Desktop\repo\code\trunk\Ganji\Ganji.Repo.Tests\testrepo";
using (var repo = Repository.Init(path))
{

}

There were two failures observed:
1) [DllImport] has trouble finding the git2.dll when it's on a UNC path.
2) The underlying init call fails on a UNC path.

@nulltoken nulltoken added a commit to nulltoken/libgit2 that referenced this issue May 23, 2012
@nulltoken nulltoken fileops: Make git_futils_mkdir_r() able to cope with Windows network …
…paths

Partially fix libgit2/libgit2sharp#153
dc07184
@nulltoken
libgit2 member

@chrisparnin Thanks for reporting this.

1) [DllImport] has trouble finding the git2.dll when it's on a UNC path.

In order to make sure I correctly understand how to repro this, could you check the following assertions?

  • You wrote a .exe that relies on LibGit2Sharp
  • The .exe sits in a folder next to the LibGit2Sharp .dll
  • The NativeBinaries folder contains the libgit2 binaries and is also located at the same level than the .exe
  • When this .exe is executed "locally" everything works ok
  • When this .exe is executed through a network path you encounter the described issue

2) The underlying init call fails on a UNC path.

A fix has been proposed regarding this issue (cf libgit2/libgit2#720)

@chrisparnin

1) Correct. On a network mounted path it would exhibit the error. Relocate to a normal path, it would be fine.

Ganji.Repo.Tests.exe
LibGit2Sharp.dll
NativeBinaries\x86\git2.dll

I played with the code that was setting the Environment path for dlls and setting the app config to point to the private dll to no avail.

2) After I moved the project to a local path, it was still having problems opening a git repository that was on network path -- looks like that's been fixed in the libgit2.

@nulltoken
libgit2 member

@chrisparnin I started investigating the probing issue and have been able to successfully reproduce it. This indeed throws a DllNotFoundException.

This fails when being lauched from a full network path (eg. \\computer_name\share\boom.exe) and even from a mapped network drive (eg. Z:\boom.exe).

I used a minimalist Console app to reproduce it. Source code is available in this Gist. It's been compiled against a 3.5 framework and depends on the latest LibGit2Sharp v0.9.0 Nuget package.

Note: The path that is added to the PATH environment variable looks correct.

@nulltoken nulltoken added a commit to nulltoken/libgit2sharp that referenced this issue May 28, 2012
@nulltoken nulltoken Upgrade libgit2 binaries to 4c977a6
Partially fix #153
a2efc1a
@nulltoken nulltoken added a commit that closed this issue May 28, 2012
@nulltoken nulltoken Upgrade libgit2 binaries to 4c977a6
Partially fix #153
a2efc1a
@nulltoken nulltoken closed this in a2efc1a May 28, 2012
@nulltoken nulltoken reopened this May 29, 2012
@nulltoken
libgit2 member

Partial fix released in v0.9.5.

DllNotFoundException issue still pending

@nulltoken nulltoken reopened this Jun 8, 2012
@nulltoken
libgit2 member

@davidfowl @davidebbo I'd need your advice on the DllNotFoundException topic.

In order to workaound the loader issue, @xpaulbettsx proposed me the following scenario.

  • Embed the binaries as resources within the assembly
  • Update the static ctor of NativeMethods to dynamically extract (if not already existing) the correct version (x86/amd64) of the binary in %TEMP%

Beside fixing this issue, this would also greatly ease the deployment (for instance, cf. here and there). However, I'd like to make sure that we're not aiming a shotgun at our own foot.

What's your feeling about this? Would this dynamic extraction cause any issue in IIS/Azure environment? Would "executing" some code from %TEMP% be frowned upon by antivirus or security related programs?

@phatblat phatblat pushed a commit to phatblat/libgit2 that referenced this issue Sep 13, 2014
@nulltoken nulltoken fileops: Make git_futils_mkdir_r() able to cope with Windows network …
…paths

Partially fix libgit2/libgit2sharp#153
6e884f5
@ethomson ethomson closed this in dc07184 Nov 25, 2014
@nulltoken nulltoken reopened this Nov 25, 2014
@carlosmn carlosmn closed this Apr 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.