- They implemented the now infamous UAC - User Access Control, (or User Account Control depending on who you're listening to).
- They designated several important areas within the operating system as "protected" areas - you are unable to write to these areas without specially elevated privilege levels.
- However - to maintain backward compatibility with older programs written for XP - they allowed a special exception: If a non-privileged process attempted to access a privileged (protected) area, a write-enabled copy would be created that would be accessed as if it were the original.
- They way they accomplished this is by using a special directory called the Virtual Store.
- This directory is located at:
C:\Users\[current user]\AppData\Local\VirtualStore
and it contains an image (copy) of any protected items that were accessed by non-privileged processes.
The idea has merit. Older programs written for XP or before, that automatically assume that EVERYONE is an Administrator level user and write all over the system willy-nilly will be given access to the Virtual Store instead of the Real Application. Virii who wish to install themselves into the Program Files directory get side-tracked to the Virtual Store - or raise a UAC - instead of just sneaking in.
- If a non-privileged application attempts access to a privileged area (C:\Program Files\MyApp, for example), a copy of the thing they tried to access is copied to the Virtual Store.
Viz. It would be copied to:
C:\Users\[current user]\AppData\Local\VirtualStore\Program Files\MyApp
. . .and the application would be given access to the Virtual Store instead of the real program path. - If a non-privileged application tries to access a protected area, AND there is already an image of the object requested in the Virtual Store - the application is automagically re-directed to the copy instead of the original. In other words, if C:\Users\[current user]\AppData\Local\VirtualStore\Program Files\MyApp already exists (in the Virtual Store), then any reference to C:\Program Files\MyApp will automatically be redirected to the copy in the Virtual Store - AND - as far as the executing process is concerned, it will actually appear to be executing out of the C:\Program Files\MyApp directory!
- Pivileged applications - running as true administrator equivalents via the UAC or by inheriting elevated privilege - always get access to the real file, not the copy in the Virtual Store.
This is all well-and-good, but if you're paying attention, you will have noticed a subtle issue has crept into the system:
- If I publish a periodic (or bug fix) update to MyApp\. . . . the updater or .MSI file that does the updating will actually and truly write to the real Program Files folder.
- However, once the update is done and the non-privileged application starts to run again, it only sees the cached version of the file in the Virtual Store's folders.
- AND -
- The presence of an updated version in the Real Folder does NOT trigger a refresh of the cached data in the Virtual Store!
- Never store data or user-generated configuration files in a protected area, such as Program Files.
- When the non-privileged application begins to run - before it does ANYTHING else - it should check the Virtual Store manually - via the explicit path - and see if there is a "MyApp" directory there.
- If there is a virtualized copy there, delete it.
- Installer software or .MSI updaters should follow the same rule when they begin running.
This will force Windows to update the Virtual Store so that when the non-privileged application runs - and accesses data in the Virtual Store - that it will always get the latest-and-greatest version.
Note that this workaround will also work on a legacy system running XP or earlier - since the path to the Virtual Store will NEVER exist on these earlier systems, the program's logic will simply skip past that and go on to launching the application.
Note that this workaround will also work on a legacy system running XP or earlier - since the path to the Virtual Store will NEVER exist on these earlier systems, the program's logic will simply skip past that and go on to launching the application.
Jim
I wanted to let people have control under where their games, sets and decks are stored, but I am not so sure it was a good idea. The folder names are a bit cryptic anyway (based upong the game GUID). Moreover if a user chooses some restricted folder as “Program files” it may have errors when using limited accounts (by default under Vista and 7).
ReplyDelete