I have a git repository for an Excel Addin I wrote, so the path is "C:\Program Files\Microsoft Office 15\root\office15\Library\BTRTools" (That 'Library' path is the required install parent of Excel add-ins for them to work properly, so I can't change it). I have UAC turned on in both Win7 and Win8.1. In Win7 everything works fine, however in Win8.1 I get a status of basically 'everything changed' (but even some weirder stuff of files first mentioned as 'deleted' then mentioned again in same status as 'untracked'. The repository is really 'clean', despite what git status says, but I can't pull or do reset --hard or anything.

If I run 'Console2' (the app from which I issue git bash commands from) using the 'Run As Administrator' option, everything works fine and the status is clean (no changes listed). And I can do a pull and any other command correctly.

In both Win7 and Win8.1 I have manually granted Full Access rights to the BTRTools folder for my user (even though I am already part of the Administrators group in both) and verified that Console2 is indeed running as my local user in Win8.1.

Has anyone experienced this problem before and have any ideas on how I can get Console2/git to work properly in Win8.1 without resorting to always running (getting prompted) Console2 in 'Run As Administrator' mode?

Thanks in advance.

Update

I discovered I got the same behavior in Win7 under a specific condition. I wrote a script to batch process several git commands by creating and running a c# Process/ProcessStartInfo and it was displaying the same behavior as the Win8.1 Console2. Calling the exact same commands directly in Win7 console vs the Win7 script (i.e. git status) displayed two different results.

The script (which was written in LINQPad) was running as my current user, but I am assuming that when it created and launched a Process/ProcessInfo it was somehow running under a different user. I was able to correct this problem in my script by providing my credentials

p.UserName = Environment.UserName;
p.Password = new System.Security.SecureString();
foreach( var c in password.ToCharArray() )
{
    p.Password.AppendChar( c );
}

Note: I verified that the security groups/settings for the 'my' user in both Win7 and Win8.1 appear to be same (part of Admin group).

Update: Get-ACL Output

I ran Get-ACL | format-list on the /BTRTools directory on both machines. The only difference was that Win8 had 'Application Package Authority' for basically all folders and Win7 did not. Not sure if that hints towards anything.

Update: SOLVED

Thanks to @ian-boyd for pointing me in right direction. On my Win7 machine where Console2/Git work fine, I discovered I had the following file:

C:\Users\terry.aney\AppData\Local\VirtualStore\Program Files\Microsoft Office 15\root\office15\Library\BTRTools.git\index

I'm not sure when that was created. If I removed it, my Console2/Git on Win7 started to 'fail' just like the behavior Win8 was presenting. I restored it on Win7, and copied it over to Win8 and now Console2/Win8 is behaving correctly as well. I've bigger battles to fight so I'm moving on. I don't really understand this, but as a side note, here were some of the steps I tried

• Setting full file/directory access to \Git install directory for Users group per this page
• Turning off Virtualize file and registry write failures to per-user locations per the same page in #1.
• Setting full file/directory access to \Library directory for Users group.

If anyone has any opinions on the 'correct' way to handle this, I'm all ears.

My guess is that Git has attempted to write files where it does not have access.

Windows then tries to keep the buggy Git going by re-directing the write someplace else. Check your

%AppData%\Local\VirtualStore

folder for redirected writes. For example:

C:\Users\Ian\AppData\Local\VirtualStore\Program Files\Microsoft Office 15\root\office 15\Library

My guess is you will find files there.

A correctly written Windows application would include an embedded option that asks Windows to not redirect failed writes. But i'm guessing Git is not a correctly written Windows application.

Bonus Chatter

From Understanding and Configuring User Account Control in Windows Vista

User Account Control: Virtualize file and registry write failures to per-user locations

This setting defines virtualization settings for 32-bit applications. Virtualization does not apply to 64-bit applications.

Configuration options:

• Enabled - If a 32-bit application with no manifest file attempts to write to a protected location like the Program Files directory, virtualization will redirect those operations to a locations in the file system and registry that all users can access. This setting enables standard users to run pre Windows Vista applications that have historically required the user running the program to be an administrator.
• Disabled - If a 32-bit application with no manifest file attempts to write to a protected location like the Program Files directory, the write will fail and the application will silently fail to run.

Default value: Enabled

Recommendation: Keep this setting enabled in environments where software must be run that is not fully compliant with UAC. Any 32-bit non-administrative application without an application manifest file or an application database entry is not UAC compliant. Many enterprises must run pre Windows Vista software, and therefore, should keep this setting configured to Enabled.