3

I have an old application which creates and updates 2 files directly in "C:\Documents And Settings\All Users". This software used to work like a charm under Windows 2000 and Windows XP. However, since we have moved to Windows 7, we have had problems with updating those 2 files.

After a quick investigation, I discovered that the file permissions on the files were too restrictive for our application to work correctly. So I have tried changing the file permissions to grant full control to the user Everyone. This worked fine the first time we update the files, but after the first write, Windows 7 restored the file permissions to some default values. I also tried to take ownership of the "C:\ProgramData" folder, and grant full control again to Everyone, but again, after the first write operation, the file permissions are restored to the default settings.

The User Account Control setting is currently set to "Notify me when programs try to make changes to my computer (do not dim my desktop)". If I turn it off, the problem disappears. However, this is not a viable solution for customers using our software.

It is not possible for me to change the location of those two files. How can I grant full control over specific file located in "C:\ProgramData" while preventing the Operating System from restoring some default permissions?

0

2 Answers 2

3

You can't do what you want to do (directly). The preferred option would be to update your software to handle paths correctly. However, what you can do is use the Application Compatibility Toolkit to create a shim.

What the shim can do is for that one executeable it can redirect all reads and writes from C:\ProgramData to something like C:\ProgramData\ProgramName and you should be able to set the permissions on the ProgramName folder and have the permissions saved.

The ACT is a complicated system and has a steep learning curve. A detailed explanation of how to set it up and then create a shim would be too large for this site's format. I recommend reading the MSDN and trying to do it yourself and if you end up having any trouble coming back here with specific issues you run in to.

I also would recommend checking over on the ServerFault site for questions about the ACT as you are venturing outside of the "power user" world and in to the "IT Professional" world and you may find better resources there.

1
  • I feared such an answer. As I said, modifying our application is not possible, so I'll look into creating a shim. Thanks for your help ;)
    – Laf
    Nov 19, 2013 at 14:40
1

I happened to have found a workaround that works better for my situation, since I cannot modify the source code, nor do I have the option of spending a whole lot of time learning about the Application Compatibility Toolkit (as suggested by Scott Chamberlain).

Using symbolic links in my case was a huge time/cost saver. From a command prompt, run the following sequence:

move C:\ProgramData\SomeFile.bin C:\Test
mklink C:\ProgramData\SomeFile.bin C:\Test\SomeFile.bin 

Provided that every required users have the required access to the new file location (C:\Test in this case), everything is transparent to the application.

As I mentioned, this is only a workaround. Scott's answer is the correct way to do it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .