Git Extensions - Can't push to git bare repository in a network drive on Windows

Question

I'm learning git on Windows, I have installed Git Extensions (Version 2.47.3) and played a bit with it. I've created a bare repository in my C: unit (as a central repository) and a personal repository anywhere else in my hard disk.

I commit, push and pull with no problems with this two repos in my hard disk.

Now I have created a new bare central repository that is not in my hard disk but in a network drive, let's say: //myShare/centralRepo/ and a new personal repo(local hard disk). I've commit for the first time in my personal repository on my master branch and made a new branch called develop. Then I wanted to push to my central repo, and here comes the problem.

It starts the process, writing objects until 73% (17/23) where it hangs for a while, after that shows the error:

"C:\Program Files (x86)\Git\bin\git.exe" push --recurse-submodules=check --progress "//myShare/centralRepo/" refs/heads/master:refs/heads/master
Counting objects: 23, done.
Delta compression using up to 4 threads.
fatal: sha1 file '<stdout>' write error: Broken pipe
remote: error: unable to create temporary file: File exists[K
remote: fatal: failed to write object[K
error: failed to push some refs to '//myShare/centralRepo/'
Done

I googled a lot and already searched in stack overflow but didn't find a clue. I tried different locations and folders, diferent network drives and the result is always the same. Am I missing something?

Thanks

Answer 1

The problem was that I'm under a Novell Network, if I use the automatic mapped drives, the push fails.

This post gave me the clue: http://git.661346.n2.nabble.com/Problem-pushing-to-a-Novell-share-td7248875.html

The problem seems to be that Novell Networks throws a Error 80 "File exists" if a directory does not exist, while it actually should be Error 3 "Path not found". It all happends in create_tmpfile() function in sha1_file.c

And here it's been one more time discussed Git push fail to a Windows share

So the workaround is to use the ip address of the mapped drive (as remote repo) instead of using its UNC path or the assigned drive letter.