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.


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.

  • Thanks. Very confusing. How would having cmake in my path (or not) make any difference though? The problem is I'm trying to debug this cmake file, since it's not working properly.
    – Dan
    Jan 30 '12 at 22:17
  • Sorry, I was assuming you were running cmake against the file. In order to use whatever the file is you will have to write it elsewhere then you should be able to use Explorer to copy the file over, you should get a UAC prompt asking you to make sure this is what you want to do and after that your file should get overwritten. The main thing is that you can only use UAC aware programs (like Explorer) to copy/write files in those locations.
    – Mokubai
    Jan 30 '12 at 22:28
  • Disabling UAC is not the only work around. You just need to give the file/directory that is causing problems Modify permissions to the Users user group by going to the security tab of the file/folder. Feb 7 '13 at 2:30
  • LOL this behaviour is bizarre! It explains a lot of the weirdness I've had. Thanks.
    – Jez
    Feb 11 '18 at 13:33

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:


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:


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.

  • Thanks. This (and the accepted answer) solved a very mysterious problem I was having. Makes perfect sense now that it is explained. Your answer is short and directly to the point. +1 Thanks! Mar 9 '13 at 7:42

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.

  • Ugh, you don't need to take ownership. Just give the Users group modify permissions. However you should not be given full access to program files. The default of everyone being a administrator is was a bad design choice and they attempted to fix it in Vista. Feb 7 '13 at 2:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.