Why can't I edit a "Program Files" file on Windows 7?

Question

I'm having trouble editing this file on Windows 7:

C:\Program Files (x86)\CMake 2.8.7\share\cmake-2.8\Modules\FindJNI.cmake

If I edit it in Cygwin (vi) or TextPad, those two programs see the changes, so it's getting written to disk somewhere. But if I "type" the file in a DOS cmd shell, it looks like the file hasn't been changed at all.

One thing I noticed is that in the cmd shell, the owner is Administrators, but in Cygwin's bash shell, the owner is Dan:

C:\Program Files (x86)\CMake 2.8.7\share\cmake-2.8\Modules>dir /Q FindJ*
 Volume in drive C is Windows7_OS
 Volume Serial Number is 92CA-8707

 Directory of C:\Program Files (x86)\CMake 2.8.7\share\cmake-2.8\Modules

12/30/2011  09:45 AM             1,480 BUILTIN\Administrators FindJasper.cmake
12/30/2011  09:45 AM             7,951 BUILTIN\Administrators FindJava.cmake
12/30/2011  09:45 AM            10,632 BUILTIN\Administrators FindJNI.cmake
12/30/2011  09:45 AM             1,669 BUILTIN\Administrators FindJPEG.cmake
               4 File(s)         21,732 bytes
               0 Dir(s)  132,524,654,592 bytes free


Dan@home /c/Program Files (x86)/CMake 2.8.7/share/cmake-2.8/Modules
$ ls -al FindJ*
-rwx------+ 1 Dan            None 10636 Jan 30 13:57 FindJNI.cmake
-rwx------+ 1 Administrators None  1669 Dec 30 09:45 FindJPEG.cmake
-rwx------+ 1 Administrators None  1480 Dec 30 09:45 FindJasper.cmake
-rwx------+ 1 Administrators None  7951 Dec 30 09:45 FindJava.cmake

How can this be? It's like there are two different files with the same name in the same directory.

Answer 1

Due to security features introduced with Windows Vista (UAC) any non-Administrator program that tries to write to protected locations such as "Program Files" will get their writes caught and redirected to an alternative "user friendly" location.

The program that made the file will be able to see the file, but most other programs will not.

Wikipedia states (and I've highlighted the relevant section):

Applications written with the assumption that the user will be running with administrator privileges experienced problems in earlier versions of Windows when run from limited user accounts, often because they attempted to write to machine-wide or system directories (such as Program Files) or registry keys (notably HKLM). UAC attempts to alleviate this using File and Registry Virtualization, which redirects writes (and subsequent reads) to a per-user location within the user’s profile. For example, if an application attempts to write to “C:\program files\appname\settings.ini” and the user doesn’t have permissions to write to that directory, the write will get redirected to “C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\settings.ini”.

So in theory your changed file is actually being written to C:\Users\YourUserName\AppData\Local\VirtualStore\Program Files (x86)\CMake 2.8.7\share\cmake-2.8\Modules

The only way around this restriction is to completely disable UAC, which is not recommended for security reasons.

The best solution is that should actually have cmake in your path and be using a non-protected location such as somewhere inside your user profile.

Answer 2

The Program Files folder is protected by Administrator rights. In Windows XP and earlier, most people ran as Administrator all of the time. Many programs assumed this was the case and did all their work in the Program Files folder.

When Windows Vista was released, they stopped this practice, forcing applications to instead use:

C:\Users\%Username%\AppData

This broke a lot of older applications. To allow older application to continue using Administrator only folders, Windows created a virtual store to keep altered files in. Take a look in:

C:\Users\%Username%\AppData\Local\VirtualStore

You'll find your files there. You can also use Explorer by opening the folder and pressing the Compatability files button at the top of the window.

Answer 3

I had a similar problem, shortly after moving to Windows 7 (from XP) I was trying to unzip a file inside C:\Program Files and it kept giving me an Access Denied error.

After much wrestling I found that I had to take ownership of the entire folder before I could change the permissions to allow the Administrators group Full Access—which, in my opinion, it should rightly have.

In order to take ownership of a folder: right-click on the folder and go to Properties, then click on the Security tab, then click Advanced, then the Owner tab, and click Edit. Check "Replace owner on subcontainers and objects", then select the new owner (e.g., the "Administrators" group), then say OK.