Search code examples
gitvmwarevmware-workstation

File in git repo becomes inaccessible

I am sharing my git directory (where I keep all my git repos) between my win 10 workstation and a Linux VM running on VMWare Workstation. After a while of working with it, the script I'm working with (called aws_utils.sh) becomes inaccessible.

I just saved some changes to a file, committed and pushed them. Then I switch branches. And I see this message:

 git checkout update_aws_list_rds
error: unable to create file aws_utils.sh: Permission denied
Switched to branch 'update_aws_list_rds'
D       aws_utils.sh

I did NOT delete this file. It's my main file and I would not do that.

I then take a look at the permissions of that file and they look like this (under linux):

-????????? ? ?       ?       ?            ? aws_utils.sh

And I can't do anything with the file:

ls -lh aws_utils.sh 
ls: cannot access 'aws_utils.sh': Permission denied

Even as root, I am unable to even list the file:

ls -lh aws_utils.sh 
ls: cannot access 'aws_utils.sh': Permission denied
whoami
root

And then a few minutes later the file is just GONE as if I had deleted it. And doing a git pull does not restore the file.

I have to literally delete the directory and clone it again to get the file back.

I check in the update_aws_list_rds branch and the file that was gone before I deleted the directory is there after I clone the directory again.

I am using git version 2.17.1 and VMware player 15.

What is going on that could cause this? How can I stop this problem from happening?

Solution

  • This:

    I am sharing my git directory (where I keep all my git repos) between my win 10 workstation and a Linux VM running on VMWare Workstation.

    is almost certainly the problem.

    This kind of shared storage never works right.1 It plays particularly poorly with Git, which insists on being in full, complete, 100% control over its .git directories. There are two rules of thumb for using Git this way:

    1. Don't do it.
    2. If you must do it, make sure you do it 100% read-only from at least one side.

    Since Git already has its own sharing protocol, it's pretty easy to set up a VMWare or VirtualBox system so that the host and client are just two different machines, with two different Git repositories, that use git push and/or git pull to transfers objects between them. That way each Git can be in full, complete, 100% control over its own .git and the corresponding work-tree, and that does work fine.

    What, never?
    Well, hardly ever!