HTML File in ProgramData folder 1

[chelseatech]

I've got a windows service that writes a HTML file to indicate it's status and recent activity. The file is in a dedicated folder in the c:\ProgramData\... area.

On my Vista machine, inside File Manager, the date on the file is recent, and the preview pane shows the expected contents. But when I double click on the file and view it in IE (8.0) it shows contents from several months ago.

This problem does NOT occur with the same service running on XP or Win 2K.

Editor and Publisher of Crystal Clear

http://www.chelseatech.co.nz/pubs.htm

 

[dilettante]

Not enough detail, but here's a guess:

If the program doesn't have an application manifest that declares it "Vista aware" the system will apply an appcompat ahim to it when writing to a protected location like this. The written file will be redirected to a per-user virtualized location instead of writing it to the ProgramData subfolder.

If you add a manifest with the necessary <trustInfo> section the program will get an I/O exception instead, such as error 70 "Permission Denied."


The usual fix for this is to have your application installer create a data folder under ProgramData, and set the permissions to allow read/write/create or full access. Normally you set this for your service's user if well known, or possibly for a user Group, or in extreme cases the Everyone group if you can tolerate this level of insecurity.

An alternative is to use another location altogether, such as a folder on another drive. This isn't so handy though if the application must be installed into arbitrary machines that don't necessarily have a D:\, E:\, etc.


None of this is new to Vista/Win7. However on earlier OSs people often left ProgramData unsecured, or they ran applications in a user context with admin or power user levels of privilege. Even if you use an admin user in Vista the default is to use a non-privileged user context token. This is the "split token" security model introduced in Vista.

You might also look at Securing a Windows Service in Windows Vista.

 

[dilettante]

Sorry, "ahim" above was a typo, should say "shim" instead.

I also didn't mention that virtualized files are sort of "shadowed." Explorer is probably showing you the virtualized file, but opening it for read access would hit the original file that is actually under ProgramData.

 

[chelseatech]

My understanding is that the folder redirection occurs with Vista and Windows 7 if you use folders in Program Files or Program Files (x86). It was the Microsoft developers who told me to use the ProgramData folder for any files used in common by applications. I should point out that the windows service and my desktop user are running under different user accounts.

The file seems to be in the correct place and is being updated. it's just that File Manager and IE get different contents of that file.

Editor and Publisher of Crystal Clear

http://www.chelseatech.co.nz/pubs.htm

 

[dilettante]

ProgramData is the "right" place in most circumstances, but you have to deal with the security on subfolders and files created there.

I just made a small program with two buttons. One button creates a file under ProgramData and writes a line of text there with the curent date and time. The other button opens the file back up, reads the line of text, and displays it.

I ran the program once elevated ("run as administrator") and clicked the 1st button to create the file. Then I waited a few minutes and reran the program without elevation and clicked the 1st button again, replacing the file with a new file having the new timestamp in it.

After this I ran the program a 3rd time, elevated again, but clicked the 2nd button to retrieve and show the timestamp written in the file.

Then I ran the program a 4th time, unelevated, and clicked the 2nd button to read/display the timestamp line of text again.

The 3rd and 4th runs display different values because they are reading two different files!


The unelevated runs were actually working against a file named:

[tt]C:\Users\<user>\AppData\Local\VirtualStore\ProgramData\pddemo\file.txt[/tt]

The elevated runs work against the file:

[tt]C:\ProgramData\pddemo\file.txt[/tt]


To prevent this from happening you need to create the "pddemo" folder and set security on it to give all necessary users full access, or at least read, write, modify, and probably list contents. By default folders created here get a special set of ACLs granting "owner access." This means whoever creates a file has full access to it, but other users get read-only access. As I said before, generally your installer package would be responsible for taking care of this.

A non-owner trying to replace or modify such a file results in a virtualized file being created, unless the process is marked "Vista aware" which results in a security exception.

 

[BadBigBen]

it may just be something simple as cleaning out the Temporary Internet files, aka cache...


Ben
"If it works don't fix it! If it doesn't use a sledgehammer..."
How to ask a question, when posting them to a professional forum.
Only ask questions with yes/no answers if you want "yes" or "no"

 

[chelseatech]

Thanks. That solved it. I hadn't noticed the "Compatibility Folders" button when on the ProgramData folder. I've set the permissions properly, and deleted the file that was causing the problem.



Editor and Publisher of Crystal Clear

http://www.chelseatech.co.nz/pubs.htm