Last updated 18 May 2011.

It many cases the Windows VirtualStore shouldn't cause problems with Git; Windows virtualizes the location of any files written to it and the application reads the files from that location. However, problems caused by VirtualStore have been reported, including this one (http://drupal.org/node/1126818) specifically concerning Git.

Background

Windows Vista and Windows 7 User Access Control (UAC) introduced a feature called the VirtualStore which is designed to add an extra layer of security protection for applications installed under the Program Files folder. All changes made to files in, and any attempt add files to, the Program Files folder and sub-folders (directory and sub-directories) requires a special Administrative permission. This is done so that stray and possibly malicious programs and files do not intermix with or overwrite legitimate ones to insure that Program Files is always intact and not corrupted.

Applications often write configuration and other temporary files within their own installation folder or sub-folders during normal use. (Note: Some temporary files are not written to the application’s folder or sub-folders, and therefore aren’t affected by this.) Because UAC is designed to ensure that Program Files remains completely unchanged from when applications were initially installed, it prevents these files from being written and other changes from happening in all folders under Program Files. Instead, changes to configuration files and additional added or temporary files are written to the VirtualStore. This is located in the: /User/AppData/Local/VirtualStore folder, and corresponding sub-folders.

Possible Fixes

There are several ways to fix this problem, if it occurs on your system:

  1. Disable UAC completely. This may be a good choice but it can introduce security issues because Program Files and other locations will no longer be protected from possible malicious files or other changes.
  2. Disable only the VirtualStore feature not the entire UAC. A possibly better choice if you feel this feature is not important to the way you use your computer. This can be done by going to Local Security Policy -> Local Policies -> Security Options and Disabling User Account Control: Virtualize file and registry write failures to per-user locations
  3. Install Git (mysysgit for Windows) outside of Program Files. This may work in most cases and is certainly worth trying. UAC is primarily designed to protect Program Files, not other locations.
  4. Inform Windows UAC that it can trust the Git application. This is probably the best choice if you're having this problem. Under UAC applications do not normally run under Administrative level access; they use User level access instead. (This is the way Linux and similar operating systems work.) However, you can tell Windows to trust Git at the User level and allow it a higher level of access than normal. This allows the application at the User level to write any changed or added files to its folder and bypasses the VirtualStore.

    This is done by right-clicking on the Git folder under Program Files. Then click Properties that appears on the context menu. The Properties dialog will appear. Click the Security tab and then select Users from the Group or User names: List box. The permissions for Users needs to changed, so click the Edit button. Select Users from the Group or User names: List box. Check the Full Control checkbox in Permissions for users:. Click through all the OK buttons and the permissions for users will be changed for the Git application.

Comments

Diogenes’s picture

One can also select the directory of the program affected by the virtual store, select Properties, then the Security tab. Edit Permissions and add yourself as a user name and give yourself full permissions. Finally, delete the virtual store directory of the same name that is the secret VS directory (expose hidden and system files to find it).

i.e. /User/%username%/AppData/VirtualStore/Program Files (x86)/Foobar

It's a way of selectively working around the VS without compromising other security.

Great blog here on a related VS gotcha and a good MS page on the topic.