It works most of the time, but every once in a while an AccessViolationException pops up

I've isolated and reproduced the issue by running ConfigurationFixture.CanReadStringValue(). Failure occured while releasing the configurationSafeHandle.

I'm no interop wizard, but this post, this SO answer and this other one seem to deal with this kind of issue.

Removing the string return values does indeed make the AV go away. How does this look?

Hey Guys,

I think I have a problem that has something todo with this issue.
(I already tried the dahlbyk:issue74 branch. It did not solve my problem)

What I did:

1. Created an empty repository
2. Created a directory inside the working directory, (new folder was named "Project")
3. Created a new file inside The Project directory (filename: Project.zip)
4. Added the Project.zip to the index using Repository.Index.Stage(path)
   Additional information: OS: WinXP, path is something of "D:\path\to\Project\Project.zip"
5. Empty step, see below
6. Commited the changes via gitLib2Sharp
7. Pushed the changes to the upstream repository
8. Cloned the upstream repository into a different directory
9. ==> Working directory is empty

Step 5:
Using a external tool (TortoiseGit, mysysgit 1.7.6) I can see the following:

$ git status
On branch master

Initial commit

Changes to be committed:
(use "git rm --cached ..." to unstage)

   new file:   "Project\\Project.zip"

Untracked files:
(use "git add ..." to include in what will be committed)

   Project/

The file was added with two \ inside the path, the Project/ directory was not added.
I think this is the reason why my working directory is empty after the clone in step 8.

Any idea how to fix this?

Hey @Flonix,

There's a rebased version of @dahlbyk's work on my repo https://github.com/nulltoken/libgit2sharp/commits/filepath
It hasn't been merged yet because it fails on our CI server (Win2003/x64) and we haven't had the time to investigate this issue yet.

Any idea how to fix this?

A quick fix would be to call PosixPathHelper.ToPosix() at the beginning of RemoveFromIndex() and AddToIndex() methods. If you happen to test this approach and make it work I'd be very grateful if you could send a Pull Request with this fix. This would be very helpful to others while we troubleshoot the x64 issue.

In theory a ToPosix() call should be redundant for RemoveFromIndex() and AddToIndex() since the native method expects a FilePath: https://github.com/nulltoken/libgit2sharp/blob/filepath/LibGit2Sharp/Core/NativeMethods.cs#L124

@dahlbyk you're right. If one work against the filepath branch.

However when working against master (which doesn't include the FilePath class yet) this should solve the issue @Flonix encounters (at least, I hope so :) ).

The quick fix I was talking about was not supposed to be applied on top of the filepath branch, but on top of master while we make filepath work on the CI server. Sorry if I was unclear.

Jep, that was unclear ;-)

I will try to fix it ontop of the master branch first.

It sound like this issue will be fixed with the upcoming filepath branch. Right?
If yes, a push request may be obsolete...

Thanks so far.

Hi again,

see the issue74 branch in my repo https://github.com/Flonix/libgit2sharp/tree/issue74.

I just did what you mentioned above.
I called PosixPathHelper.ToPosix() from inside AddToIndex() and RemoveFromIndex().

This works for me.

I identified one more problem that has something to do with posix/native path issue on windows.

If you try to get the RepositoryStatus using the Repository.Index.RetrieveStatus() method,
you will alwas get Posix paths.

It would be nice if someone likes to look at a minimum change I made.
It is currently located in the path-issue1 branch in my repository.

I also did some further changes to deal with ignored files when using the RetrieveStatus(string filePath) method.
It seems that gitlib2 itself currently doesn't deal with ignored files.
I prepared the RepositoryStatus to deal with ignored files, but I am not sure if this is enough.
Please have a look at the path-issue2 branch on my repository, which holds the further changes.

@Flonix Thanks for your contributions. I commented each of your proposals in their respective branches.

BTW, next time, it'll be easier if you open a new Pull Request instead of adding comments to an already existing one. You can find more onto this subject in the help section.

@nulltoken: Thanks for the comments.

The path-issue1 branch has a new commit which fixes the missing statusEntries.

Sorry for 'reopening' this pull request. I just didn't realize that it is a PullRequest because it is already listed as issue.

I will open a new pull request for the path-issue1 branch.

Update for latest - was never able to repro the CI failure. Can you wire up a build for testing?

Update for latest

Thanks a lot! Merged into vNext. The CI server seems happy now :)