In my view, perhaps better named the virtually crazy store. Read about what the Windows VirtualStore is but in a nutshell, it is a feature added since Windows 7 that “helps out” by creating virtual copies of files transparently, on-the-fly, without any notification or warning. While a lot of what is written talks about legacy support for applications that write to the Program Files directory, we’ve found it also appears to impact the %allusersprofile% directory.
Real and Virtual Files
Here at DataCraft Analytics we have an ETL application that we use to extract, package, encrypt, transport, decrypt and load data. It is called Analytique. The application is configured using an xml file, stored in the %allusersprofile%\DataCraft\Analytique\ folder. The application can run either with an User Interface, or more often than not, as a scheduled task, or a windows service. We generally opt to run the application unattended as a scheduled task. From time to time, we have some issues with the configuration working when we test it through the UI (e.g. logged in), compared with when we are logged out, with it running as a scheduled task. The scheduled task is usually run in a different account, and therefore sometimes security context to the user account we log in to configure it with.
The culprit to this very perplexing issue is the Windows Virtual Store.
If the process accessing the settings file cannot write to it, then a copy of the file that should have been written is created in the virutal store instead of its real location. From that point on, Windows transparently loads the virtual store file for the user that created the virtual copy, not the actual one. All other users apparently still load the real file (or in an even more nightmarish scenario their own virtual copies). This results in different configuration information being displayed depending on which user is running the application. If we’d wanted this to happen, we wouldn’t have used the %allusersprofile% directory to store configuration files, instead opting to store user specific configuration files in the appropriate place.
Once the virtual store file is created, it appears to always be given preference, even if you sort out the permissions issues that were causing it in the first place. See the example below of the two files, one is loaded transparently without any configuration settings, while the other is loaded with all settings intact.
To solve the problem to revert back to only a single copy of the file with no virtual files:
- Change the permissions on the real file or folder causing the issue in the first instance – usually by granting write / modify or full control to the appropriate user account or accounts.
- Take a copy of the VirtualStore folder at fault by creating a zip up or a copy. Then delete the folder from the VirtualStore path. We don’t recommend deleting the folder outright without a copy in case you’ve got some configuration or data in the folder that your application needs.