git on vagrant shared folder

Dear git-Team, we recognized a behavior that comes up with a newer git version. Unfortunately we do not know which version exactly.

The problem: For development we are using virtual box controlled via vagrant with a shared folder on windows and mac hosts. The virtual OS ist ubuntu 14.04.2 LTS. In march this year we started with git in version around 2.3. With cloning a repo directly in the shared folder we haven’t had any problems. A few weeks ago we weren’t able to clone and get an error: could not commit /vagrant/.git/config file. Manually we were able to change that file and also the clone command works outside the shared folder.

We retried it again with git version 1.9.1 (I think the standard of ubuntu 14.04 LTS) and it worked. So the break seems to be around 2.4.

I hope you are able to understand the problem and can do something. Please tell me if this is not a real bug.

Thanks a lot for the greatest VCS in the world.

Greetings from Berlin.

Mit freundlichen Grüßen
 
Peter Hüfner
.........................................................
e·confirm GmbH ..
Travel.Software.Training.Consulting
 
Geschäftsführer: Roman Borch und Michael Posthoff
HRB 35653B   Steuernummer 37/211/10880
10119 Berlin Linienstr. 214
 
Tel.  +49 (0) 30 28 00 28 24 
Fax. +49 (0) 30 28 00 28 28
 
www.e-confirm.de
.................................................................................................

Hi, I don't know if this helps you, but I found two strange things with your history that I want to point out.

On Tue, Jul 14, 2015 at 05:49:43PM +0200, Peter Hüfner wrote:

So you're running git on windows/os x and store the files on a shared folder on Ubuntu? This will have some strange side effects. Synchronization errors with the shared folder and the different file systems used might cause a problem (or might not). This is a unusual usecase and _very complex_ use case. I wouldn't be surprised if it breaks (git have had several bugs on shared folders before).

My advise is to run git on the same machine as you store the git repo on. Git should not be runned over a network (no matter if the network is local on your computer or not).

Why are you trying to commit a file inside the .git dir? Files in that dir should not be commited (and I'm pretty sure there was a patch about this a while ago). The .git/config file for example is local to each git repo and should not be commited.

Actually it is considered a security risk, see http://article.gmane.org/gmane.linux.kernel/1853266

Hi Stefan, Hi Frederik,

maybe I stated the case not clearly enough.

The repo is just inside an shared/mounted folder from the VM to the Host, so that we can access the sourcecode via an IDE running on the host. The git commands are executed inside the VM on an ubuntu system. So there is no mix of operating systems in the repos directly. The shared/mounted folder is underlying some restrictions, such as no filemode and case insensitive filenames. But with git we can handle this.

We do not commit any file inside the .git folder. The error (could not commit .git/config file) comes up while the git-clone command executed inside the shared folder.

I tried to clone the repo outside the shared folder and copied it inside afterwards. As I was doing the configuration for filemode and case with the git-config command, I got the same error (could not commit .git/config file). But I was able to update the .git/config manually. So it is not only an access problem, because I can access the file.

The security risk is stated with version 2.2.1, but we were able clone in the shared folder with git 2.3. So the change must be in an higher version.

Maybe I am able to install a few versions of git and try the scenario for them, then i should be able to determine the version explicit.

Thanks again for your help. I hope I could state the problem a bit more detailed for you.

Mit freundlichen Grüßen
 
Peter Hüfner
.........................................................
e·confirm GmbH ..
Travel.Software.Training.Consulting
 
Geschäftsführer: Roman Borch und Michael Posthoff
HRB 35653B   Steuernummer 37/211/10880
10119 Berlin Linienstr. 214
 
Tel.  +49 (0) 30 28 00 28 24 
Fax. +49 (0) 30 28 00 28 28
 
www.e-confirm.de
.................................................................................................

Stefan Beller <sbeller@google.com> writes:

I do not think Peter meant to "git add .git/config && git commit" by referring to the 'could not commit config file' error message he saw; you two are going in a wrong direction.

    $ git grep 'could not commit'
    config.c: error("could not commit config file %s", config_filename);

I do share Fredrik's suspicion that the virtual filesystem the Ubuntu guest is trying to write to is at fault, but I never used "vagrant shared", and I do not know in what specific way their filesystem is not behaving as we expect.

Applying 7a64592c (config.c: fix writing config files on Windows network shares, 2015-06-30) might be an interesting thing to try. Some filesystems do not want to rename a file that has mmaped region still active, which is my blind guess.

Junio is absolutely right. I wasn’t trying to commit that file directly. The error comes up when I want to change the config via git config or when I clone the repo. I also know that a shared folder is not a very friendly environment, but it is the best solution for our situation here. We recognized the error first time in the beginning of july, so the change done in june 30 seems to be a reason. I will stay up to date and try it with newer git versions.

Mit freundlichen Grüßen
 
Peter Hüfner
.........................................................
e·confirm GmbH ..
Travel.Software.Training.Consulting
 
Geschäftsführer: Roman Borch und Michael Posthoff
HRB 35653B   Steuernummer 37/211/10880
10119 Berlin Linienstr. 214
 
Tel.  +49 (0) 30 28 00 28 24 
Fax. +49 (0) 30 28 00 28 28
 
www.e-confirm.de
.................................................................................................