application manifest issues, comments?

short version:
Are there undesired consequences of adding the necessary options to disable file virtualization (a UAC "feature") to an embedded application manifest?
( see http://www.codeguru.com/csharp/csharp/cs_misc/designtechniques/article.php/c15455/Tip-To-Disable-Virtualization.htm )

In Windows Vista, 7, and 8, an external manifest file can apparently be ignored for various seemingly arbitrary reasons.

long version:
The Aardwolf version of the GMCP mapper plugin (the one included in the Aardwolf MUSHclient package) includes a feature to perform regular integrity checks and backups of the sqlite database.

Occasionally the following scenario occurs (two accounts of this have been reported to me thus far)...
Someone on Windows 7 or 8 will experience file corruption and try to scrap their MUSHclient directory and start over. Erasing the MUSHclient directory, which they have invariably placed somewhere protected by UAC security, has the undesired result of leaving behind their old corrupted database files in the secret VirtualStore at %LOCALAPPDATA%\VirtualStore\Program Files\MUSHclient because Windows Vista+ by default virtualizes all file writes in secured areas to user-specific storage. And it, kind of stupidly at this point, does _not_ delete the virtual store when the MUSHclient folder is removed or overwritten.
So what happens, apparently, is that the next time MUSHclient loads, it accesses the old, corrupted files again, because those files exist in the virtual store.

So I got a report that this happened to a second user this morning, and I started to investigate options. As far as I can tell, my options are as follows:
1) Make sure that users never put the MUSHclient folder into a UAC protected space like Program Files
2) Construct an installer or other special program that deletes the virtual store.
3) Provide information on how to delete the virtual store in the event that the above scenario occuring again to another user
4) Block file virtualization entirely using the application manifest

Obviously (1) is impossible to enforce, and (2) limits directory portability.
I'm adding (3) to my website already, but I wanted to go further and just prevent the problem.
So I tried to create a manifest for MUSHclient.exe that would disable file virtualization. I followed a bunch of instruction pages and called it MUSHclient.exe.manifest and put it into the MUSHclient folder. But it wasn't working. Apparently external file manifests can be ignored for all kinds of reasons. So in order for this to work I think it would have to be embedded in the executable.

Thoughts?

Stepping back to the real problem (the file corruption) is there a way of detecting that? For example, a SQLite3 integrity check done before you try to do the "real work".

I do periodic integrity checks already as stated. The question then becomes how one restores from a backup after detecting db corruption.

I must be missing an important step here. If you detect corruption, you delete and re-create the database file (from within the app). If virtualization puts the file somewhere else, so be it. Then you restore from the backup.

Well, at the moment I leave restoring from backups up to the user (manually, outside of the app). I am considering the possibility of doing this automatically within the app, but in any case let's imagine for a moment that there are no valid backups yet or that the backups have been deleted by the user or whatever other thing can happen.

In the event that the user attempts to replace the directory with a brand new download, they will seemingly find, to much surprise, that the old files are still there supplanting the new ones. I'm not sure exactly the conditions that cause this to happen, but I have seen it occur. The problem appears to be that the VirtualStore is not erased when the original files are.

<sigh>

Windows, eh?

You have a file, it is in the directory where you want it, that being the directory that the app plans to use, but Windows chooses to use a different file.


Can you work around this by doing things the Windows way? For example, the mapper database, don't put it anywhere near where the MUSHclient.exe file is. Make sure you open/write/read to it in a supported directory, like My Documents.

Agreed. Keeping the old VirtualStore around after the directory is removed or replaced is so dumb it defies description.


This is something I'm not readily willing to do without some serious thought, because people have a pretty strong expectation that the MUSHclient folder is self-contained. A number of Aardwolf players use things like USB keys and Dropbox for portability.

I am planning now to try to restore from backups automatically. With any luck that will further reduce the cases of this particular scenario.

That's exactly why it was done that way in the first place. The whole app was self-contained.

Now Windows throws a spanner in the works by silently redirecting files away from where they appear to be.

I can understand why, in a way. I was gobsmacked when I found out that under (earlier) Windows versions you could read/write to the Program Files folders as if they were just straight data. That fails in so many ways it is hard to describe. And this was after reading about how Windows had ACLs, permissions, blah, blah. But then they let programs, in the normal course of execution, store their data in Program Files.

However, it worked in the sense that it kept everything together. So I wasn't in a big hurry to split things up into some other (what?) folder where it might be safe to put user data.