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.

5 years later, you might hope the issue (Git commands with unwanted UAC with VirtualStore) has been fixed, with Git 2.23 (Q3 2019)

See commit fe90397 (27 Jun 2019) by Cesar Eduardo Barros (cesarb).
^{(Merged by Junio C Hamano -- gitster -- in commit 9b9b24b, 11 Jul 2019)}

mingw: embed a manifest to trick UAC into Doing The Right Thing

On Windows >= Vista, not having an application manifest with a requestedExecutionLevel can cause several kinds of confusing behavior.

The first and more obvious behavior is "Installer Detection" of the "User Account Control" (also known as "UAC") feature, where Windows sometimes decides (by looking at things like the file name and even sequences of bytes within the executable) that an executable is an installer and should run elevated (causing the well-known popup dialog to appear).
In Git's context, subcommands such as "git patch-id" or "git update-index" fall prey to this behavior.

The second and more confusing behavior is "File Virtualization".
It means that when files are written without having write permission, it does not fail (as expected), but they are instead redirected to somewhere else.
When the files are read, the original contents are returned, though, not the ones that were just written somewhere else.
Even more confusing, not all write accesses are redirected; Trying to write to write-protected .exe files, for example, will fail instead of redirecting.

In addition to being unwanted behavior, File Virtualization causes dramatic slowdowns in Git (see for instance msysgit issue 320)

A third unwanted behavior of Windows >= Vista is that it lies about the Windows version when calling GetWindowsVersionEx().

There are two ways to prevent these unwanted behaviors:

Either you embed an application manifest (which really is an XML document conforming to a specific schema) within all your executables,

or you add an external manifest (a file with the same name followed by .manifest) to all your executables.

Since Git's builtins are hardlinked (or copied), it is simpler and more robust to embed a manifest.

Recent enough MSVC compilers already embed a working internal manifest, and building with mingw-w64 (which is the case in Git for Windows' SDK) does it, too, but for MinGW you have to do so by hand.

In any case, it is better to be explicit about this manifest, that way changes in the compiler toolchain won't surprise us (as mingw-w64 once did when it broke GetWindowsVersionEx() by mistake).

References:

New UAC Technologies for Windows Vista

Create and Embed an Application Manifest (UAC)